iWorm method of infection found!
Published October 4th, 2014 at 7:29 AM EDT , modified October 5th, 2014 at 1:45 PM EDT
On Thursday, I wrote about new malware called iWorm. This morning I awoke to find an e-mail waiting for me in my Inbox from someone who wished to remain anonymous. This person indicated that he had found installers for the new iWorm malware. He pointed me to the downloads offered by a user named “aceprog” on PirateBay.
On this user’s PirateBay page, I found installers for a number of different commercial products, such as Adobe Photoshop, Adobe Illustrator, Microsoft Office and Parallels. Actually downloading one of these things was a maze of clicks and redirects to adware sites, but I finally settled on installing a torrent client and using the torrent download link, which gave me a stolen copy of Photoshop CC 2014.
The item that got downloaded included some unsavory items that could be installed or opened to allow the stolen copy of Photoshop to run without a valid license, and although you couldn’t pay me to use any of these things on a real system, none of them turned out to be the problem. It turned out that the official-looking Photoshop installer had been modified:
Submitting the three executable files inside the installer to VirusTotal revealed that the one titled “0” was detected by only a small handful (3) of anti-virus engines. The other two were not detected as malicious at all. Presumably the “Install” executable is legit, but I’m left wondering about the “1” item.
I wasn’t sure what to expect when opening the file. One would hope that modifications to the app would result in the app being identified by Mac OS X as damaged, since the installer was signed. (The cryptographic signature on Mac OS X apps is meant to verify that the app was made by a particular developer and that it has not been modified.) However, opening the Install app resulted in a different warning:
This is further puzzling, since the app appears to have a code signature. However, running “codesign -vv” on the Install app reported that the app was not signed. At this point, I overrode the Gatekeeper restrictions for this app and forced Mac OS X to run it anyway.
The very first thing that happened when I opened the app was that I was asked for my admin password. I provided it, and an official-looking Adobe installer started up, but by then the damage was done. The instant I provided the password, the iWorm malware was installed.
Looking at fs_usage output (which provides detailed information on file system activity – such as file and folder creation), it appears that the only things added to the system by the “0” executable are the following items:
/Library/Application Support/JavaW/JavaW /Library/LaunchDaemons/com.JavaW.plist
The com.JavaW.plist file simply runs the JavaW process at startup, ensuring that the malware is constantly running in the background.
I reset my test system to a clean state, then ran the installer again, but this time I clicked the Cancel button when asked for my admin password. In this case, the malware was not installed at all.
There has been some speculation that a Java vulnerability may be involved, probably based on the “JavaW” name. However, at this point, it looks like this is far more prosaic. It’s just a trojan in the form of pirated software that has been modified.
The moral of the story? Never engage in software piracy. This single piece of malware is FAR from the only thing you can get infected with while installing stolen software. Torrents and sites like PirateBay should be avoided at all costs. If you cannot afford to pay for a piece of software or a movie or something similar, do without. Downloading such things for free often come with LOTS of strings attached.
I am also submitting this to Apple’s product security team… hopefully we will see an update to XProtect shortly.
October 5, 2014 @ 7:48 am EST: I woke up this morning to find that Apple had released an XProtect update overnight. It now includes definitions for iWorm.A, iWorm.B and iWorm.C. The iWorm.A hash matches the “install” executable file in my sample, and testing shows that my sample will no longer install on a system with up-to-date XProtect definitions. I don’t know what the other two definitions match yet.
Also, I received further information from my anonymous tipster that this malware won’t install if the folder /Library/Little Snitch/ is present (ie, if Little Snitch is installed). However, I wasn’t able to verify this in testing… the malware installed just fine with Little Snitch installed. This may be a behavior exhibited by some variants of this malware, but not others. Or there could have been something uniquely different about my testing and his testing that caused the variation in behavior.
October 5, 2014 @ 1:41 pm EST: A clarification… the malware still gets installed with Little Snitch installed, but it will apparently bail out immediately when it runs.