The PhoneType argument contains the model of the infected phone (e.g nokia3250, nokian95…), while the PhoneImei and PhoneImsi arguments respectively contain the phone’s IMEI and IMSI. The Source argument is new to this variant, and its use has not been reversed yet. It could possibly contain the name of the malicious website used to infect the phone.
The first of those JSP pages, Jump.jsp, redirects the user to a Chinese mobile social networking site (3g.kaixin001.com then wap.kaixin001.com). Actually, we had already noticed this behaviour in at least 2 former JSP pages used by previous versions.
The second JSP page, Kernel.jsp, actually replies the following string (host name removed):
And, from this location, we get a new minor variant of Yxes.D. This is a consistent behavior in Yxes: the worm indeed often works in pairs (e.g variants A, B, D or E download variants C, D or F). In this case, variant H silently downloads and installs a remotely hosted new version of variant D.
Its certificate says:
Serial Number: 2a:2f:00:01:00:23:37:98:0c:73:b2:c7:69:17 Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, O=Symbian Limited, CN=Symbian CA I Validity Not Before: Jan 23 17:55:42 2010 GMT Not After : Jan 24 17:55:42 2020 GMT Subject: C=CN, ST=Fujian, L=XiaMen, O=Xiamen Jindoucheng Tech Co. Ltd., OU=plugucsrv 2.1.0, OU=Symbian Signed ContentID, CN=Xiamen Jindoucheng Tech Co. Ltd.
A notification has been sent to Symbian, who tells us the certificate should soon be revoked. Meanwhile, be cautious if you encounter a file named plugucsrv.sisx that installs as a ‘Setting Wizard’.
That variant D then actually does most of the malicious work: collect data on the phone, report it back to the malicious web servers and send SMS messages. The URLs it contacts are:
The PhoneNumber, Succeed, Fail and Time arguments are obviously used to report contacts listed on the phone. The Succeed and Fail arguments are followed by an integer, probably the number of times that phone number has successfully been called or not.
Quite interestingly, if we try to get http://XXXX/bs.jsp, using a credible user agent (the malicious websites are known to check user agents – in particular, if it detects Internet Explorer, it responds “404 Not Found”):
SUCCESS reponse: 200 OK http://hew1ett-packard.com/bs.jsp?
Notice the letter L of Hewlett has been replaced the number 1 (one).
So, the first malicious web server redirects the requests to another malicious web server, whose name is obviously intentionally crafted to fool the end-user. The URL does not respond any longer. Note that the Yxes worm is already known to use such mispellings:
The third JSP, KernelPara.jsp, is still a mystery we have to work on. It returns a file named encrypt_Kernel_Para.txt. If its name is meaningful, it is likely to be an encrypted version of a file named Kernel_Para.txt (the worm already uses files with similar names: Local_Para.txt and Remote_Para.txt). In our case, its content is fixed and 32-byte long. It is not an XOR encrypted URL.
Finally, to evaluate the worm’s authors progress, it is interesting to follow the dates and versions of samples. The dates are taken from the first validity date in the X.509 certificate used to sign the sample, and the version numbers are included either in the main executable of the sample or in the certificate.
Apart from a sporadic ‘accident’ end of June 2009 where a version 1.0 goes in the wild (probably an error in versioning), we see the worm authors are continuously working on Yxes since the end of 2008. So my first prediction for 2010 was nearly bound to be true…
– The Crypto Girl
Author bio: Axelle Apvrille's initial field of expertise is cryptology, security protocols and OS. She is a senior antivirus analyst and researcher for Fortinet, where she more specifically looks into mobile malware.