Topics

Beware of 'XCSSET' malware hidden inside Xcode projects


 

Use caution opening Xcode projects downloaded from the interwebs: There’s a new(ly-discovered) exploit that hides inside projects and installs malware when the target is built, using a rogue build script. (And not just a regular run-script build phase; it pretends to be an asset catalog compiler, to make it harder to notice.)

"The XCSSET Malware: Inserts Malicious Code Into Xcode Projects, Performs UXSS Backdoor Planting in Safari, and Leverages Two Zero-day Exploits"

(As reported in this week's iOS Dev Weekly, and previously covered on Twitter apparently.)

This is worrisome. It's not news that basically all build systems are Turing-complete and can do arbitrary stuff at build time. And legit projects frequently need to run scripts to move or process files. But once people start weaponizing this, it becomes a pretty nasty way to spread malware.

At a minimum, I think it'd be a good idea to look through the contents of all .xcodeproj bundles in any project source you download, before opening or building them. (And don't use the Finder, as some files are hidden; use `tree` or a Git client or something.) In the case of this particular exploit, a ".xcassets" directory is a giveaway.

This also makes using CocoaPods or Carthage scarier, as you only have to enter a URL into a config file to trigger downloading a sub-project sight unseen.

I don't know what the solution to this is going to be … sandboxing Xcode's build engine seems like a good idea, to prevent it and any scripts it runs from writing to files outside the build directory. Hopefully Apple is taking this seriously.

—Jens


2551phil
 

Hope this doesn't come across as a sales plug, not least because it's been free since the start of COVID :), but I develop a tool that detects the presence of that (and much else in the macOS malware/adware/keylogger space).



Phil



On 15 Aug 2020, at 02:18, Jens Alfke <jens@...> wrote:

Use caution opening Xcode projects downloaded from the interwebs: There’s a new(ly-discovered) exploit that hides inside projects and installs malware when the target is built, using a rogue build script. (And not just a regular run-script build phase; it pretends to be an asset catalog compiler, to make it harder to notice.)

"The XCSSET Malware: Inserts Malicious Code Into Xcode Projects, Performs UXSS Backdoor Planting in Safari, and Leverages Two Zero-day Exploits"

(As reported in this week's iOS Dev Weekly, and previously covered on Twitter apparently.)

This is worrisome. It's not news that basically all build systems are Turing-complete and can do arbitrary stuff at build time. And legit projects frequently need to run scripts to move or process files. But once people start weaponizing this, it becomes a pretty nasty way to spread malware.

At a minimum, I think it'd be a good idea to look through the contents of all .xcodeproj bundles in any project source you download, before opening or building them. (And don't use the Finder, as some files are hidden; use `tree` or a Git client or something.) In the case of this particular exploit, a ".xcassets" directory is a giveaway.

This also makes using CocoaPods or Carthage scarier, as you only have to enter a URL into a config file to trigger downloading a sub-project sight unseen.

I don't know what the solution to this is going to be … sandboxing Xcode's build engine seems like a good idea, to prevent it and any scripts it runs from writing to files outside the build directory. Hopefully Apple is taking this seriously.

—Jens


 



On Aug 14, 2020, at 12:21 PM, 2551phil <2551phil@...> wrote:

Hope this doesn't come across as a sales plug, not least because it's been free since the start of COVID :), but I develop a tool that detects the presence of that (and much else in the macOS malware/adware/keylogger space).

Does it specifically detect XCSSET? Because the current version of DetectX Swift.app is dated July 4, whereas the PDF describing XCSSET was released in the past few days*, and two of the exploits therein are described as zero-days, meaning they were not previously known.

—Jens

*  (I don't know the exact date, but the text refers to an infection that occurred on July 31, so it must be after that, and none of the Google hits for "XCSSET malware" are dated earlier than yesterday.)


2551phil
 

Yes it does. 

In this case, it uses a heuristic to catch XCCSET not a traditional "AV" sig. But that said, the search engine also does poll my server when it runs for more traditonal sigs also that evade the heuristics.






On 15 Aug 2020, at 02:29, Jens Alfke <jens@...> wrote:



On Aug 14, 2020, at 12:21 PM, 2551phil <2551phil@...> wrote:

Hope this doesn't come across as a sales plug, not least because it's been free since the start of COVID :), but I develop a tool that detects the presence of that (and much else in the macOS malware/adware/keylogger space).

Does it specifically detect XCSSET? Because the current version of DetectX Swift.app is dated July 4, whereas the PDF describing XCSSET was released in the past few days*, and two of the exploits therein are described as zero-days, meaning they were not previously known.

—Jens

*  (I don't know the exact date, but the text refers to an infection that occurred on July 31, so it must be after that, and none of the Google hits for "XCSSET malware" are dated earlier than yesterday.)


2551phil
 

And FWIW, to be fair to my "competitors", Malwarebytes also catches this (not by heuristic, but so long as the malware hits certain paths). I'm sure there's quite a few other solutions that have updated recently that cover it, too.


Best


Phil

On 15 Aug 2020, at 02:32, 2551phil <2551phil@...> wrote:

Yes it does. 

In this case, it uses a heuristic to catch XCCSET not a traditional "AV" sig. But that said, the search engine also does poll my server when it runs for more traditonal sigs also that evade the heuristics.

<Screenshot 2020-08-14 at 15.43.02.jpg>





On 15 Aug 2020, at 02:29, Jens Alfke <jens@...> wrote:



On Aug 14, 2020, at 12:21 PM, 2551phil <2551phil@...> wrote:

Hope this doesn't come across as a sales plug, not least because it's been free since the start of COVID :), but I develop a tool that detects the presence of that (and much else in the macOS malware/adware/keylogger space).

Does it specifically detect XCSSET? Because the current version of DetectX Swift.app is dated July 4, whereas the PDF describing XCSSET was released in the past few days*, and two of the exploits therein are described as zero-days, meaning they were not previously known.

—Jens

*  (I don't know the exact date, but the text refers to an infection that occurred on July 31, so it must be after that, and none of the Google hits for "XCSSET malware" are dated earlier than yesterday.)



2551phil
 

I almost forgot to mention...there's an XProtect rule for it, too. 

That only catches one component of it (the run-only main.scpt mentioned in the TrendMicro report), but until today I wasn't aware of XCCSET so it might be that there's other rules there. I will check tomorrow.

Quite possibly the built-in MRT.app may search for the other components, but you have ot reboot for that to kick in (it does kick in when they update it silently in the background, but that won't help you if you got infected after it was updated).


Best


Phil



On 15 Aug 2020, at 02:36, 2551phil via groups.io <2551phil@...> wrote:

And FWIW, to be fair to my "competitors", Malwarebytes also catches this (not by heuristic, but so long as the malware hits certain paths). I'm sure there's quite a few other solutions that have updated recently that cover it, too.


Best


Phil

On 15 Aug 2020, at 02:32, 2551phil <2551phil@...> wrote:

Yes it does. 

In this case, it uses a heuristic to catch XCCSET not a traditional "AV" sig. But that said, the search engine also does poll my server when it runs for more traditonal sigs also that evade the heuristics.

<Screenshot 2020-08-14 at 15.43.02.jpg>





On 15 Aug 2020, at 02:29, Jens Alfke <jens@...> wrote:



On Aug 14, 2020, at 12:21 PM, 2551phil <2551phil@...> wrote:

Hope this doesn't come across as a sales plug, not least because it's been free since the start of COVID :), but I develop a tool that detects the presence of that (and much else in the macOS malware/adware/keylogger space).

Does it specifically detect XCSSET? Because the current version of DetectX Swift.app is dated July 4, whereas the PDF describing XCSSET was released in the past few days*, and two of the exploits therein are described as zero-days, meaning they were not previously known.

—Jens

*  (I don't know the exact date, but the text refers to an infection that occurred on July 31, so it must be after that, and none of the Google hits for "XCSSET malware" are dated earlier than yesterday.)




David Delmonte
 

Is it possible that external code say through Cocoapods, could be infected?

Bad year for viruses. sigh


On Aug 14, 2020, at 3:29 PM, Jens Alfke <jens@...> wrote:



On Aug 14, 2020, at 12:21 PM, 2551phil <2551phil@...> wrote:

Hope this doesn't come across as a sales plug, not least because it's been free since the start of COVID :), but I develop a tool that detects the presence of that (and much else in the macOS malware/adware/keylogger space).

Does it specifically detect XCSSET? Because the current version of DetectX Swift.app is dated July 4, whereas the PDF describing XCSSET was released in the past few days*, and two of the exploits therein are described as zero-days, meaning they were not previously known.

—Jens

*  (I don't know the exact date, but the text refers to an infection that occurred on July 31, so it must be after that, and none of the Google hits for "XCSSET malware" are dated earlier than yesterday.)


 



On Aug 14, 2020, at 1:01 PM, David Delmonte via groups.io <ddelmonte@...> wrote:

Is it possible that external code say through Cocoapods, could be infected?

Definitely, since a Cocoapad repo contains an Xcode project that's added as a subproject of your app.

—Jens