I had already seen mobile malware SMS messages with a malicious URL inside (e.g SymbOS/Yxes), or MMS messages (e.g SymbOS/Album.A!tr, SymbOS/Beselo!worm…) with a malicious attachment. However I had never noticed a mobile malware piece sending a WAP Push SMS (special SMS messages typically used to send ringtones, wallpapers, OTA provisioning etc).

The recent SymbOS/NMPlugin.A!tr does all three ! It sends:

- an MMS, whose title is “Hello Skuller”, and contains an attachment named Sunset.jpg

- a SMS containing a short message and a malicious URL from which to download another Symbian malware. This message is written in Chinese (it uses the UCS2 character set) and says something about some of your friends having uploaded two videos to the malicious URL

- a WAP Push SMS message, using China Mobile’s cmwap access point, and sent to UDP port 2948. This port is typically used for WAP Push Service Indication messages (WAP 167).

WAP Push Service Indication messages are special SMS meant to notify the end-user that a new service is operational at a given URL. Unfortunately, so far, the body of the message hasn’t been identified, so we cannot be sure this is what the malware is actually sending. However, if this is the case, a WAP Push Service Indication would be particularly dangerous for at least two reasons:

First, WAP Push messages are usually considered as high priority SMS and hence often automatically displayed on the mobile phone (see ‘signal-high’ parameter in WAP 167). For an attacker, this is nice because there are higher chances the message will be read by the victim.

Second, on some phones, a vulnerability prevents the phone from correctly displaying the originator of the message,so the victim may think the URI is sent by his/her (trusted) operator (see Figure below). For attackers, the downside is that WAP Push messages are not supported by all mobile phones.

Figure 1. Example of WAP Push SI message that does not correctly display the originator. The victim may consequently think the URL comes from a trusted party (system administrator).

– the Crypto Girl.

Two major operating system releases have officially come to end of life this month. On July 13th, Microsoft dropped support for both Windows 2000 and Windows XP SP2, meaning no more patches will be rolled out for these operating systems. This includes both Windows 2000 Server and Professional, as well as all editions of XP SP2.

Of course, in terms of security, this is a significant development since any new vulnerabilities discovered that affect these products (and there are many on an ongoing basis, just have a look at our NVC coverage here) will not be patched, and thus will remain wide open to attack. Key protection elements we always recommend against vulnerability exploits include patch management and intrusion prevention. With no further patches offered, operating system patch management effectively becomes null and void. While the best course of action is to upgrade to an operating system which supports up-to-date patches, it may take some time since a full OS upgrade can change many components and functions on a system that need to be tested. While thinking of upgrade paths, it becomes very important to guard against attacks that will continue to target these (now) legacy systems. Even once an upgrade is complete, the very same safeguards should be applied since they will help protect against future zero-days before they are patched; and even attack attempts when a system has been fully patched.

As a recent example, let’s examine CVE-2010-2568 – the “.LNK” vulnerability that’s been a hot topic (a.k.a. Stuxnet). As of writing, this issue has not been patched by Microsoft and it is likely that when a patch is released, Windows 2000 and XP SP2 will not be supported since they are now past end of life. There are several mitigation layers to this issue, two of which lie in antivirus and intrusion prevention. For example, in our labs, we have developed both IPS and antivirus signatures to detect against the malicious “.LNK” files that exploit this vulnerability.

Through analogy, an unpatched system with antivirus and intrusion prevention at the gateway is like a vaultless bank with police enforcement on the scene 24/7/365. There’s never one silver bullet to stop a threat through all of its vectors, but proper security practices combined with a serviced security solution that supports technologies such as antivirus and intrusion prevention is certainly a valid approach. FortiGuard Labs regularly adds protection through both antivirus and intrusion prevention for new vulnerabilities, and will continue to add definitions for vulnerabilities that affect Windows 2000 and XP.

The analysis of SymbOS/NMPlugin.A!tr shows that, once again, a mobile malware was signed using the Symbian’s Express Signed procedure. It is the fourth malware we notice doing so since 2009 (and it is likely I missed a couple). See the table below.

Our July 2010 Threat Report has been posted, below are some findings from the activity recap:

Global detected malware volume continued its rise from last report, reaching levels observed earlier in the year. One major contributor to this was the Sasfis botnet, as it continued its strong run. Eight Sasfis variants landed in our Top 10 Malware listing this report. This is a recurring theme, as developers and their very own creations continue to roll out updated copies of themselves. Earlier in the year, the Sasfis botnet was dedicated to downloading and executing software (primarily FakeAV) on infected systems. This period, we observed Sasfis to heavily spam as it downloaded updated spamming modules. Typical examples of spam from Sasfis include fake UPS invoices and Facebook photo links.

Spam bots such as Cutwail continue to diversify, sending a variety of spam themes on a frequent basis. One spam email we observed from Pushdo was a phish for Amazon.com. This is a classic phish, easily detected by hovering over the link and observing where you are really going. Prevalent spam campaigns this report varied from phishes, to attached HTMLs that redirected users to malicious sites, to emails with malicious attachments themselves. The diversity of these spam campaigns, and their targets, shows how botnets continue to serve the needs of their underground customers. Two emails showcased in the report use money transfers as social engineering. In both cases, HTML files were attached that contained malicious, obfuscated javascript. When executed, end users would be redirected to malicious sites.

Over 30% of our newly covered vulnerabilities continued to be exploited, an ongoing trend that we have witnessed for well over a year. There were a total of 91 new vulnerabilities added this period, showing that hackers continue to exploit a large number of known security holes. The report breaks down these vulnerabilities by severity, the majority of them being rated ‘High’. This gives an idea of scope, severity and in the-wild-activity. In itself, this reflects the importance of quickly patching security holes as fixes become available – on top of having IPS detection. Even with proper patch management in place, all it takes is one zero-day vulnerability to be exploited (even in low volume) to potentially cause a significant impact. For an example in July, look no further than the Stuxnet attacks (read our FAQ here). While the attack is under investigation, the fact that a trojan associated with the exploit was seemingly developed to target industrial control systems underscores this point. Further, this is also a good example of how little interaction is required by the end user to become infected. The Stuxnet exploit attacked a Windows Shell vulnerability (CVE-2010-2568) to launch its attack by simply opening a folder (thus viewing an icon). If you can remember, we saw a similar attack method with PDF files through JBIG2 image streams and Windows shell extensions back in 2009 (CVE-2009-0658): simply browsing a folder could trigger infection. Fortinet detects the vulnerability associated with the Stuxnet attack as ‘MS.Windows.Shell.LNK.Code.Execution‘, and generically detects the exploited “.LNK” payload with antivirus as ‘W32/ShellLink.a!exploit.CVE20102568‘. As of writing, there are workarounds but no official patch released from Microsoft.

‘MS.Windows.Help.Center.Protocol.Malformed.Escape.Sequence‘ was attacked in a zero-day state before Microsoft rolled out a patch for Windows Help Center (CVE-2010-1855) on July 13th. The vulnerability was publicly disclosed on June 5th, and we observed attacks happening as of June 11th. Attacks continued on a frequent basis this period, landing the attack in fourth position on our top 10 attack list. The attacks occurred through websites, however were a bit more potent considering they were not restricted to a single web browser (since they were launched through the HCP protocol handler used by all browsers). In many cases websites that serve exploits will try to fingerprint browsers and launch attack code tailored to those browsers. Like Stuxnet, this is yet another example of a zero-day vulnerability successfully attacked before a patch is made available.

I discussed in my last post how a variant of Bredolab typically resolves the API functions it needs. Basically, most malware embed an array of hash values, each corresponding to an API function, rather than storing plain API names. Then, a function is used to “resolve” hash values into the relevant API function addresses. A call to such a function looks like this (taken from actual malware):

Concretely, an array of API hashes table may look something like below (we added an “Equivalent API” column for comprehension, but of course it’s not present in the malware):

Commonly, at “encoding” time, the hash values are obtained by passing the API function names through a hash function. Then in Bredolab, resolving a hash value at run time is done by comparing it with the hashes of all the API function names in the target DLL file (which are computed on the fly by the same hash function), until a match is found.

During recent analysis, I encountered a slightly different algorithm.

The observed malware, an Oficla variant, had a list of ‘api codes’ that were obviously not plain API name hashes. Indeed, to resolve an api code into an api name, the malware did not just compare the api code to hashes of all possible “candidate” api names in the dll until it finds a match. Instead, for each candidate api, it hashed the name, combined it with the api code to resolve (following an algorithm involving several XOR operations) and then compared the result with a “magic number”, or “key”. This key is always 14c353e0.

If the combination result equals the key, then the api code is considered resolved into the candidate api (otherwise, the operation is repeated with the next api candidate).

The flowchart below sums up the whole process

Regarding the key, it may be a relevant number combination for the malware author. Perhaps a hash of his own name. Or somebody special to him. Or probably yet another random value.