SymbOS/Yxes goes version 2
A few days ago we encountered a new variant of the Symbian worm, Yxes, that we named SymbOS/Yxes.H!worm. This worm contacts malicious remote servers, which host Java Server Pages, and propagates by sending ‘attractive’ SMS messages. For instance, this new variant sends an SMS with an URL promising private information concerning a Chinese actress. Globally, the logic (and much of the code) is the same as in previous variants. Yet, there are a few updates, one of the main ones being the use of new remote malicious Java Server Pages.
I guess every analyst has noticed this variant of the malware contacts the following URLs:
http://XXXX/Jump.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=... http://XXXX/Kernel.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=... http://XXXX/KernelPara.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...
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:
http://XXXX/bs.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=... &PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=... http://XXXX/index.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=... &PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=... http://XXXX/number.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=... &PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...
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