Recently, MacOS included a signature in its integrated antivirus, intended to detect a binary for Windows; but, does this detection make sense? We could think it does, as a reaction to the fact that in February 2019 Trend Micro discovered malware created in .NET for Mac. It was executed by the implementation of Mono, included in the malware itself to read its own code. Ok, but now seriously, does it make sense?
It might make sense to occasionally include a very particular detection that has been disseminated through the media, but in general the long-term strategy of this antivirus is not so clear, although it is intended to detect “known” malware. The fight that MacOS as a whole has against malware is an absolute nonsense. They moved from a categorically deny during the early years of the 21st century to a slight acceptance for finally, since 2009, lightly fight malware. However, since then it has not evolved so much.
Let’s continue with the detection of the Windows executable: the malware was detected in February, which means that it had been working for some time. Trend Micro discovered it and the media made it public, bringing down their reputation. On 19 April, Apple included its signature in XProtect. It is an unacceptable reaction time. On top of all this, it was the first XProtect signature update during all 2019. Is it possible that the malware dissemination was related to the signature inclusion? What is the priority level given to user’s security then? Do we know how much malware is detected by XProtect and how often this seldom-mentioned functionality is updated? Are Gatekeeper and XProtect a way in general to spare their blushes or are they really intended to help mitigate potential infections in MacOS?
At least, one of the few official websites about XProtect indicates that it is addressed to prevent “known” malware from running (https://support.apple.com/en-in/HT207005).
What is what
This issue about malware in MacOS is a cyclical, recurrent (and sometimes bored) subject. However, for those who are starting out in security, it is necessary to remind them how dangerous are certain myths that last over time because there are still big “deniers”.
XProtect is a basic signature-based malware detection system that was introduced in September 2009. It constitutes a first approach to an antivirus integrated into MacOS, and it is so rudimentary that when it was launched it was just capable of identifying two families that used to attack Apple operating system and only analyzed files downloaded from Safari, iChat, Mail and now Messages (leaving out well-known browsers for MacOS such as Chrome or Firefox). Currently, XProtect has some more signatures that may be clearly found (malware name and detection pattern) in this path:
/System/Library/CoreServices/XProtect.bundle/Contents/Resources/
XProtect contains signatures on the one hand, and Yara rules on the other hand (it is defined by XProtect.plist and Xprotect.yara on that directory), and with both systems malware is detected and defined. GateKeeper is supported by both; it monitors and sends it them. The list XProtect.plist is open. Number 3 from the URL refers to Mountain Lion. When 2 is modified, Lion signature file may be viewed, and 1 corresponds to Snow Leopard. Apple does not seem keen to talk too much about it. site:support.apple.com xprotect on Google delivers little results.
Relation between xprotect.yara and xprotect.plist with some hashes
GateKeeper has little to do with malware or antivirus, as sometimes it is said. GateKeeper is a system in place to check that downloaded apps are signed by a known ID. To develop for Apple and publish on App Store, the developer must get (and pay) an ID to sign their programs, a kind of certificate. According to Apple, “The Developer ID allows Gatekeeper to block apps created by malware developers and verify that apps haven’t been tampered with since they were signed. If an app was developed by an unknown developer—one with no Developer ID—or tampered with, Gatekeeper can block the app from being installed”. Therefore, Gatekeeper is far from being an antimalware. Rather, it is an apps’ integrity, source and authorship controller that, in case it detects something untrustworthy, it will send it to XProtect and keep it in quarantine if it comes from a suspicious site.
Moreover, there is also MRT for MacOS. It’s its Malware Removal Tool, very close to the Malicious Software Removal Tool for Windows. It is used to reactively remove malware which was already installed, and it can be only executed on system start-up. As if it were not enough, to perform disinfection it trusts very specific and common infection paths, so little can be done.
Why all this does not seem to work too well
- An avoidable bit to be analyzed: XProtect is a signature-based system (leaving heuristics behind, no trace of advanced analysis system) that actually constitutes the “basis”. However, it is affected by all kind of obstacles, preventing it from being effective. GateKeeper is the system that tells XProtect, “I’m going to embed an active quarantine bit into this just downloaded file, let’s see if you detect it”. This bit may be simply removed even without privileges, so it would be easy to avoid XProtect basic checking.
- A poor update in terms of frequency and quantity: for instance, as we are stating in May 2019, XProtect has only been updated two times, with a single signature each one. The first in 2019 took place on 19 April (for the Windows malware previously mentioned), and 10 days later the second one was launched (pushing a rule to detect MACOS.6175e25 within its Yara rules). From 2009 to 2011, it moved from 2 to less than 20 signatures. How many signatures does it have currently? In its 2103 version ˗the latest of May˗ 92 signatures may be counted (gathered over almost 10 years). They are the following ones:
“OSX.CrossRider.A”,”MACOS.6175e25″,”MACOS.d1e06b8″,”OSX.28a9883″,”OSX.Bundlore.D”,
“OSX.ParticleSmasher.A”,”OSX.HiddenLotus.A”,”OSX.Mughthesec.B”,”OSX.HMining.D”,
“OSX.Bundlore.B”,”OSX.AceInstaller.B”,”OSX.AdLoad.B.2″,”OSX.AdLoad.B.1″,”OSX.AdLoad.A”,
“OSX.Mughthesec.A”,”OSX.Leverage.A”,”OSX.ATG15.B”,”OSX.Genieo.G”,”OSX.Genieo.G.1″,
“OSX.Proton.B”,”OSX.Dok.B”,”OSX.Dok.A”,”OSX.Bundlore.A”,”OSX.Findzip.A”,”OSX.Proton.A”,
“OSX.XAgent.A”,”OSX.iKitten.A”,”OSX.HMining.C”,”OSX.HMining.B”,”OSX.Netwire.A”,
“OSX.Bundlore.B”,”OSX.Eleanor.A”,”OSX.HMining.A”,”OSX.Trovi.A”,”OSX.Hmining.A”,
“OSX.Bundlore.A”,”OSX.Genieo.E”,”OSX.ExtensionsInstaller.A”,”OSX.InstallCore.A”,
“OSX.KeRanger.A”,”OSX.GenieoDropper.A”,”OSX.XcodeGhost.A”,”OSX.Genieo.D”,”OSX.Genieo.C”,
“OSX.Genieo.B”,”OSX.Vindinstaller.A”,”OSX.OpinionSpy.B”,”OSX.Genieo.A”,”OSX.InstallImitator.C”,
“OSX.InstallImitator.B”,”OSX.InstallImitator.A”,”OSX.VSearch.A”,”OSX.Machook.A”,”OSX.Machook.B”,
“OSX.iWorm.A”,”OSX.iWorm.B/C”,”OSX.NetWeird.ii”,”OSX.NetWeird.i”,”OSX.GetShell.A”,
“OSX.LaoShu.A”,”OSX.Abk.A”,”OSX.CoinThief.A”,”OSX.CoinThief.B”,”OSX.CoinThief.C”,
“OSX.RSPlug.A”,”OSX.Iservice.A/B”,”OSX.HellRTS.A”,”OSX.OpinionSpy”,”OSX.MacDefender.A”,
“OSX.MacDefender.B”,”OSX.QHostWB.A”,”OSX.Revir.A”,”OSX.Revir.ii”,”OSX.Flashback.A”,
“OSX.Flashback.B”,”OSX.Flashback.C”,”OSX.DevilRobber.A”,”OSX.DevilRobber.B”,
“OSX.FileSteal.ii”,”OSX.FileSteal.i”,”OSX.Mdropper.i”,”OSX.FkCodec.i”,”OSX.MaControl.i”,
“OSX.Revir.iii”,”OSX.Revir.iv”,”OSX.SMSSend.i”,”OSX.SMSSend.ii”,”OSX.eicar.com.i”,
“OSX.AdPlugin.i”,”OSX.AdPlugin2.i”,”OSX.Leverage.a”,”OSX.Prxl.2″
Including Eicar and the first XProtect samples of September 2009 (OSX.RSPlug.A, OSX.Iservice).
- XProtect is based on plain sight Yara rules. Yara is great for analysts to “hunt” for malware, but it is not clear whether it is the best option for detection, particularly when rules are published, making public the detection methods and under what conditions this is done. By doing this, door is being opened for malware writers to simply modify and avoid them.
- Yara rules must not only be made, but they must be well made by choosing a concrete singularity to avoid false positives and make it difficult for attackers, so that we ensure that by changing any condition they are able to attack without modifying their payload. Particularly, in this regard it stands out how Apple trust filesize to detect malware. They do it because of what we mean by “efficiency”.
Within this rule, the file is expected to be lower than 3500 bytes (the hash filesize from the example is low, barely 2k) to estimate the hash and this way detect them. Any downloaded file lower than that filesize will be compared to a few hashes, well-known since 2016. Firstly, it discriminates by filesize, and then it detects hash, both variables of little relevance. With the same size structure and hash, we are able to identify 42 of the 92 XProtect’s Yara rules that discriminate by filesize and then trust in hashes to detect malware.
They don’t only rely on hash. XProtect’s Yara rules also use significant strings to detect malware, and add the filesize at the end as a key condition to detect it.
According to this rule, the malware must be a Macho one, contain all the described strings and be lower than 200kb. If it includes all the strings but is higher than 200k, the condition is not matched and would not be detected. Using filesize within Yara rules is not strange or wrong in essence, but in these situations and as a condition for a protection system (not for “hunting”), it does not seem very strong.
And with this discriminatory filesize formula, we are able to find 27 (1/3) of the detections that would be avoided by just modifying the filesize. Remember that 42 of them (almost 1/2) would do it, besides, by tampering a single bit of the file. And all this just with 92 signatures in the “database” and only analyzing those programs from very specific channels (Safari, Mail, iChat and Messages). If we wanted to split hairs, we could mention that SHA1 is already considered obsolete to estimate the hash, but it does not matter too much in this context.
Conclusions
XProtect is not intended to compete against any antivirus, that’s the truth, and is designed to detect known malware. That said, “known malware” is not the same as “known sample”. It should cover at least families and not specific files. We should not expect a lot from it, but it must be seen as a first and very thin protection line against threats. However, we think that, even so, it would not accomplish its task. Rules use hashes to detect, they are limited, and malware definitions are always integrated long after the malware has been disseminated through the media. Anybody could claim that maybe these few signatures cover most of the known malware for MacOS, but even if it is not true, its response capability and detection formula paint an unflattering picture of the system in general. Therefore, we cannot expect a real protection, not even reactive, from XProtect. What may be expected then from this MacOS system? Purely and simply making some users feel secure by displaying a reassuring message on their systems in “ideal infection conditions”.
In their favor, it must be said that at least Apple is not Android (with a detection system as Play Protect, that is ineffective, but at least can be justified) but above all because if at least all users strictly download from Apple Store, there are some guarantees. Unlike Google Play and although its store is not free from malware, Apple Store is quite secure, as iOS and its applications are.
So now the eternal question that deniers like so much. Do you need an antimalware in your MacOS? We could answer yes, we do, but not XProtect. Do not feed the fire, but nor the myths.
Sergio de los Santos
Innovation and Labs (ElevenPaths)
ssantos@11paths.com
@ssantosv
