Who am I?
Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.
Calendar
Recently...
Categories
- Qt [1]
- Operators [1]
- Mobile Monday [1]
- Market [4]
- Security [3]
- Open Source [1]
- Palm [2]
- Mobile Monday [4]
- Symbian Foundation [5]
- Nokia [11]
- Android [16]
- Linux [6]
- Development [14]
- Innovation [1]
- Symbian [22]
- Windows Mobile [11]
- Platform Security [2]
- iPhone [19]
- UI [2]
- Mobile OS [16]
- Testing [3]
- Symbian C++ [11]
- Series 80 [0]
- Series 40 [0]
- S60 [14]
- Python [0]
- Open C [1]
- Messaging [0]
- Location Based Services [1]
- Java [3]
- General [17]
- Games [0]
- Flash [1]
- Event [5]
- Entertainment [0]
- Enterprise [4]
- Connectivity [2]
- CDMA [0]
- Business Opportunities/Services [22]
- Browsing [5]
Gabor Torok's Forum Nokia Blog
Mobile worm, Yxes.A - an analysis
tote_b5 | 20 February, 2009 11:58
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
Symbian, Security |
Next | 
Previous |
Comments (2) | 
Trackbacks (1)
Comments
Re: Mobile worm, Yxes.A - an analysis
ilsocio | 24/02/2009, 00:18
1) Actually Mark they are even more stupid than what you believe... :D
There are some sites (eg. http://cer.s603rd.cn/) which purpose is to create and distribuite DevCert to the users...
The main problem with this practice is that they have to distribute also the PRIVATE KEY (.key file) in order to allow users to use the DevCert.
With a simple search on TrustCerter database is then possible to obtain the PublisherID and then proceed with the ExpressSigned certification.
A very interesting test case...
Sorcery-ltd | 20/02/2009, 14:52
Given our recent discussion of the merits of Publisher IDs, this makes an interesting test case.
1) I'd love to find out where the Publisher ID that was used for signing this application can be traced to - I very much doubt there is any obvious connection to the author or any cyber criminals - they're just not that stupid. If they managed to do this once, surely they can do it again, and so can others...
2) I agree about OCSP checking but I think you'll find there's more than just enabling the feature in phones missing. As with most PKI stuff, the idea is good in theory but it doesn't work in practice.
3) Possibly this is 3rd Edition only and is using the old PlatSec exploits to escalate its capabilities. The example of an FP1 phone given in the report is the N73, which is plain 3rd Edition MR.
Mark