Mobile worm, Yxes.A - an analysis

F-Secure and FortiGruard both reported that a new worm, Yxes.A, is spreading on Nokia smartphones based on S60 3rd Edition platform (and probably higher, too). According to FortiGuard:

• "It gathers phone numbers from the infected device's file system, and repeatedly attempts to send SMS messages to those. The messages feature a malicious Web address (URL); upon "clicking" on the address in the received message, the recipients will download a copy of the worm (provided their phones/subscriptions allow for internet browsing)." That is, it's a Trojan.
  
• Beyond propagating to as many users as possible via the strategy mentioned above, the worm's aim is to gather intelligence on the infected victim (such as serial number of the phone, subscription number) and post it to a remote server likely controlled by cyber criminals.
  
• It's also noted that  worm can mutate easily: "As far as our analysis goes, the worm currently does not take commands from the remote servers it contacts. However, since the copies hosted on the malicious servers are controlled by the cyber criminals, they may update them whenever they want, thereby effectively mutating the worm, adding or removing functionality." It's not that simple, though. It's not like download a new EXE from the Net and it will just work. No new EXE or DLL (a plug-in, for example) can be installed without the assistance of Application Installer, which will eventually require user's attention and approval. Some files that don't have to be installed can be downloaded, though, containing instructions for the worm to execute, however, it's becoming a science fiction if we think that any malware author will put THAT much effort in developing such a system. I'm highly sceptical on that it would be a real threat and refuse to be threatened by that.
• It's also reported that "On launch, the worm executes as the process 'EConServer.exe', which is likely meant to camouflage alongside the existing legitimate system process 'EComServer.exe'". This simply doesn't mean anything: if a process name is only similar to another (system) process name then it doesn't imply anything. And anyway, EComServer.exe is never launched by hand (but by the system upon device start), consequently it's not a valid scenario that the malicious EXE gets launched instead.
• It's a very agressive application, since it "will also automatically run every time the device is rebooted / power cycled. Further, it bears a destructive nature and will kill certain processes such as the application manager (AppMgr)." If that's true then the program must hold very strong capabilities that cannot be granted by a self-signed certificate.

You can see from the list above that the worm can be malicious, indeed. Following from the last point we can conclude even more:

• The program couldn't be self-signed, since the program requires such strong capabilities that the Application Installer will never grant to a self-signed installable.
• It couldn't be signed via Open Signed Offline*, either, since that would limit the spread only to max 1000 devices with given IMEI numbers.
• It couldn't be Certified Signed*, either, since that requires a thorough test done by an official Test House. Even if they hadn't done a thorough test, such a behavior must have turned out very soon.
• All that means that it was Express Signed*. You know, one characteristic of Express Signed is that they do occasional testing, which means that there might be some malicious apps that can go through this filter.

What counter-measures can be taken? First, the certificate of the malware author must be revoked. That means that whenever they will try to publish another application, whatever it will do it will not be allowed to be distributed, but will be filtered out automatically. This doesn't comfort any victims of this virus, though (hmm, are there any?).

Second, it would be just great if OCSP-checking was enabled on every phone by default. OCSP is a protocol that allows the Installer to check it in a database that a certificate is revoked or not. Although it is available on each S60 phones, it is disabled by default. But I go even further: it's not only the Installer that should use it, but other components of the system, too. In fact, the system itself should perform such a cross-check at regular intervals if any of the installed applications have become undesirable for the user (i.e. the certificate used to sign that application has got revoked) in the mean time. I'm unsure as to why this mechanism can be disabled at all, probably because it requires a network connection and data exchange with a remote server. But I think this should be something that operators shouldn't charge for - isn't it in their best interest, too, that the devices using their network wouldn't get infected?

* For more information on various signing schemes, please visit Symbian Signed.

Any thoughts are welcome,

Tote