Since the Belarus vendor VirusBlokAda pulled the alarm last week on a new malware deemed “Stuxnet”, a whole lot of information has been released here and there on different portions of the threat. As a matter of fact, the Stuxnet case presents a certain level of multiplicity, as it consists in an “exploit” part, a “rootkit” part, involves specific infection vectors, targets a specific class of victims, and has unusual characteristics (for instance regarding software certificates). The subsequent fragmentation of information across the Web lead us to think some people may find a comprehensive FAQ – including our own bits, of course – somewhat useful.
Q: So, what is Stuxnet exactly?
A:Technically, Stuxnet is solely the name of the Trojan component of the threat. The Trojan component is split in two malicious drivers, mrxnet.sys and mrxcls.sys, both droped into System32\drivers\ during the attack.
Q: And what do these drivers do?
A: This is still under active investigation, and will be addressed in depth in an upcoming blog post. But essentially, they have rootkit features: attempting to hide themselves and to inject malicious code in key parts of the system to spy on it, and possibly act based on what it sees.
Q: Why is Stuxnet said to target SCADA systems?
A: Because in the aforementioned injected code were found strings suggesting monitoring of (and possibly interaction with) SIMATIC WinCC and SIMATIC Siemens STEP 7, two software pieces relevant to industrial processes.
Q: So, could the attack aim at shutting down the electricity grid or any other nation-wide catastrophe that terrorists would want to trigger?
A: It is too early to identify the precise aim of the attack (let alone to attribute it) but let’s consider the following: SIMATIC STEP 7 is an engineering software (i.e. it is used to design industrial controllers) and SIMATIC WinCC is mainly a monitoring software, used to visualize industrial processes. It is therefore permitted to think the Stuxnet attack is somewhat industrial espionage oriented, rather than armageddon-driven.
Q: Then if I don’t run an industrial facility, I’m safe, right?
A: Not necessarily. For starters, having a Trojan planted in your machines is never totally innocuous: the rootkit component can generate system instability due to conflicts in hooking APIs, and worse, the Trojan may be updated at some point to spy on something else than SCADA software. Furthermore, the exploit part used to “seed” the Trojan is independent from the Trojan itself. Some reports lead us to think it actually may have been used by cybercriminals as long as one month before the vulnerability was made public, possibly to seed other malware pieces. In any case, it will be used from now on.
Q: And what is this vulnerability about? How does it work?
A: The vulnerability, labeled ‘CVE-2010-2568’, is a design flaw in the way MS Windows handles .lnk and .pif files. Essentially, MS Windows has a feature allowing such files to load “control panel applets” dlls with an arbitrary path as soon as a folder containing such files is opened in Windows explorer. Apparently this is to allow for dynamic icon management on external/remote storage.
Q: OK, so opening a folder that contains a malicious .lnk file will result in a malicious dll being loaded in my system, right?
A: If the system has access to the malicious dll as defined by the path embedded in the .lnk file, yes.
Q: And what does the malicious dll do?
A: In the case of the Stuxnet attack, it drops the two drivers mentioned in the very first answer above.
Q: Why do people mention USB sticks as the infection vector, and “AutoPlay” as an infection catalyst?
A: Because with MS Windows AutoPlay, infection could be automatic upon connecting a USB stick to the system, assuming the default action is set to “open to view files”. But frankly, AutoPlay should not be the center of discussions: USB sticks primarily being storage media, a user inserting one is likely to open it at some point. Beyond that, USB sticks have two interesting properties for the attackers:
1. They can carry the malicious dll to be loaded, almost without any size restriction.
2. Being physical objects, they tend to pass through firewalls… Directly from the parking lot to the internal network.
Q: So are USB sticks the only possible infection vectors?
A: No, a remote attack could also be mounted either via Webdav or remote SMB shares, leading to the remote malicious dll being loaded into the local system. In addition, Microsoft has indicated that Office documents could be used to trigger the same design vulnerability.
Q: Ok, so how do I patch my system?
A: There is no patch available yet, however Microsoft has published some workarounds in an advisory.
UPDATE (2010-07-22): Microsoft released a tool that automates implementation of such a workaround.
Q: What is this I keep hearing about valid certificates in Stuxnet?
A: The malicious drivers mentioned above are signed by certificates issued to Realtek and JMicron, two legitimate companies. The private keys used to sign software with those certificates were likely stolen: ESET researcher PM Bureau noted that both companies have offices in Hsinchu Science Park, Taiwan.
Q: What is Fortinet doing about it?
A: We have released AntiVirus (Data/StuxnetLnk!tr) and IPS (MS.Windows.Shell.LNK.Code.Execution) detections for the malicious .lnk files, tackling the threats from different angles, in order to increase robustness of overall detection in FortiGates.
The malicious dll and drivers are taken care of by detections W32/Stuxnet!tr and W32/Stuxnet!tr.rkit, respectively.
Author bio: Guillaume Lovet is the head of Fortinet's FortiGuard security research team in EMEA and a regular speaker at international antivirus conferences.
On Symbian phones, most malware are either implemented natively in C++ (over the Symbian API) or in Java (midlets). SymbOS/Enoriv.A!tr.dial uses another language called m.
Usually, m scripts (.m extension) are run within the m environment, (mShell) using the various features offered by m library modules (messaging, obex, video, zip…). This is comparable to Java midlets, which run over a Java environment and use various Java API packages. The m scripts can also be compiled to be included in a stand-alone Symbian application. In that case, the Symbian SIS package contains the compiled m script (.mex extension) and the m runtime environment (library and resources) for the mobile phone.
So, when we unpack Enoriv, most files are actually not malicious and only related to the legitimate m environment:
Files such as dialogs.rsc, menvironment.rsc, file.rsc and file.aif are non-malicious resources (menu, icon files etc). A close look at the main application file, file.app, which is run at installation, reveals mEnvironment error codes and exceptions (ErrDied, ErrNoMemory, ExcInvalidNumber…), built-in m function names (isfunction, sleep…) and use of functions to display a GUI (CAknQueryDialog, CEikDialog…), load resources (CCoeEnv::AddResourceFile…), find .mex files, load a built-in top level class etc. So, file.app does not look alarming at all, it is the standalone m runtime environment. The only possible concern with the main application file is that it contains code to send SMS messages. We will explain that later.
The ‘interesting’ file is file.mex. A quick hexdump confirms itcontains the malicious payload:
Notice the strings at the end “opsex 3922″, “7122″, “munet 3922″, “sms”, “send”. Smells like a script sending SMS messages to premium phone numbers. But, what exactly is it sending ? an SMS to 3649 with the text “opsex 3922″ ? several SMS to numbers 3649, 3922, 7122, 1171, 8355 ? Let’s have a closer look.
As we said previously, .mex files are compiled m scripts. A developer writes an m script (extension .m), and may then compile it using the “Compile” menu of the mShell application installed on his development mobile phone.
Figure 1. Test m script file Figure 2. Compiling an m script
Unfortunately, the format of .mex is not (publicly) documented and .mex decompilers do not exist either (or not publicly). So, we have to work this out ourselves.
Obviously, .mex files begin with a “MEX” magic, followed by some formatting and finally strings. In the mShell documentation, we find there is a built-in sleep function which takes milliseconds as parameters, and a send function in the sms module, which takes a list of phone numbers as first argument and a text as second argument. We notice that, in the compiled script, function names are prefixed by 0×04 and the length of the function’s name:
0×04 0×05 sleep
0×04 0×04 send
Similarly, module names are prefixed by 0×01 and the length of the module’s name:
0×01 0×03 sms
and constants used in the script are prefixed by 0×07 and the length of the string:
0×07 0×04 3649
0×07 0×0a opsex 3922
0×07 0×04 7122
0×07 0×0a munet 3922
0×07 0×04 1171
0×07 0×04 8355
At this point, we know the malicious script:
uses the sms module
calls the built-in sleep function
calls the sms send function
uses 6 constant strings
but we do not know to which function arguments the constants correspond. To understand this, we create a basic non-malicious m script that sends an SMS (see Figure 3) to our lab’s test phone.
Figure 3. Test SMS message received by our lab’s iPhone
Then we compile it and compare its hexdump with that of the malware:
We notice that the argument to the sleep function (5 milliseconds) does not appear as a text string, and that, for the sms.send() function, the phone number appears before the SMS text message.
This consequently means that the “3649″ string is not an amount of milliseconds but a premium phone number the malware sends SMS messages to.
To understand how the other strings are organized, we need to play a little more with our non-malicious test script and, for example, have it send several SMS messages (replace with your own phone numbers):use sms
In that case, the hexdump shows the first phone number (”+00000000000″), the first message (”Msg 1″), the second phone number (”+11111111111″), the second message (”Msg 2″), the third phone number (”+22222222222″), the fourth phone number (”+33333333333″), the last message (”Msg 3″) and finally the string “sms” (reference to the sms module) and the string “send” (reference to the send function).
So, the malware sends a first SMS to the phone number 3649 with the text “opsex 3922″ and a second SMS to the phone number 7122 with the text “munet 3922″. For the remaining strings, 1171 and 8355 look like two premium phone numbers, but the 8355 could also be the SMS text. To tell the difference, we modify our non-malicious test script once more:
use sms
sms.send("+00000000000", "");
The hexdump shows the phone number (”+00000000000″), followed by a null string (0×07 0×00). As this does not occur in the malware, this means it only sends a third SMS message to phone number 1171 with text 8355. There we are, we retrieved the phone numbers and messages of all three SMS messages.
– 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.
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:
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:
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
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.
It had been a while since we’d last seen a malware transferring credits to pre-paid phone cards. Our last encounter dated back to SymbOS/Flocker!tr.python early January 2009. It is happening again, with Java/GameSat.A!tr, a Java ME midlet which is currently in the wild.
Indosat, an Indonesian telecom operator, offers IM3 (Indosat Multimedia 3) customers the ability to transfer (small) funds between two accounts. This is known as ‘pulse transfer’ or ‘M3-Transfer’ and it works by … SMS, without PIN nor registration ! The money is transferred from one IM3 account to another IM3 account (a transfer fee is charged to the sender).
This sounds quite handy, but… absolutely anything but secure, so it comes as no surprise cyber-delinquents make use of it.
In Flocker, from 5000 to 10000 Indonesian rupees (0.45 – 0.90 USD) were transferred to IM3 accounts controlled by the malware author.
Now, Java/GameSat.A!tr typically gets onto your mobile phone as a ‘modification to Opera Mini’. Of course, it does not modify Opera Mini at all. Instead, it uses IM3 fund transfer to access non-free on-line divination, chat or dating services. The end-user gets charged up to 20000 Rp (1.8 USD) – not mentioning the transfer fee – each time he/she opens the application or tries to access the non-free services.
Figure 1. The malware advertises as a modification to Opera Mini
Figure 2. Malware tries to send an SMS
I could make up my own divination service on that matter, and tell end-users they are probably about to lose roughly two dollars, get plenty of SMS spam and absolutely no advice or dates whatsoever.
– 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.
by Karine de Ponteves December 1, 2009 at 10:51 am
AV Lab’s honeypots have just started catching new malware seeding campaigns leveraging vaccination profiles for the H1N1 virus.
The message is sent as a notification from the “Centers for Disease Control and Prevention (CDC)”. Because the sender’s email is spoofed and because the URL leading to the rogue website contains a “gov” subdomain, which can be mistaken for the top-level domain, the message may seem plausible to many people.
Here is what the email looks like:
From: "Centers for Disease Control and Prevention (CDC)" <info-mess-id:01203428med@cdcmails.gov>
Sent: Tue, 1 Dec 2009 23:37:46 +0800
To: [removed]@fortinet.com
Subject: Creation of your personal Vaccination Profile
You have received this e-mail because of the launching of State Vaccination H1N1 Program.
You need to create your personal H1N1 (swine flu) Vaccination Profile on the cdc.gov website.
The Vaccination is not obligatory, but every person that has reached the age of 18 has to have
his personal Vaccination Profile on the cdc.gov site. This profile has to be created both for
the vaccinated people and the not-vaccinated ones. This profile is used for the registering system
of vaccinated and not-vaccinated people.
Create your Personal H1N1 Vaccination Profile using the link:
Create Personal Profile (link to http://online.cdc.gov.yhnbad.[removed])
And here is a screenshot of the rogue site:
Of course, the “Archive” (see “Download Archive” link) is in fact a Trojan horse.
Pay attention to those ever-going social-engineering attempts leveraging news items. Of course, this one is easily defeated by the fact the “vaccination profile” is an executable file, which is unlikely for an archive (although possible), especially sent by an official organization.
But when the malicious bits are embedded in actual documents (.pdf, .doc, .xls, etc.), it can sometimes be challenging to separate the wheat from the chaff…
Fortinet detects the downloaded file as W32/Vacc.A!tr
Author bio: Karine de Ponteves has always been into computer security and its many aspects. Her current responsibilities include preliminary analysis of malware and developing detection for new viruses.
All Posts
Twitter
FaceBook
LinkedIn
YouTube