Today’s episode was hosted by Derek Manky, Fortinet’s project manager, cyber security & threat research. Derek is an advocate of working from the ground up; understanding the drivers and methodologies of cyber crime and threats, then deriving defense strategies. Derek has presented his research world-wide at many security conferences, while educating and promoting cyber-security awareness. He has been recognized as a thought leader in the industry and featured numerous times in top tier publications.

Please check it out and share your comments. Your feedback will help to make future episodes even better.

In March 2010, we saw some elevated activity for Ransomware: malware which locks out applications and data from a users PC demanding ransom before restoring access. TotalSecurity was one such ransomware variant circulating then, and has been quite prevalent again this report. This infection has been in business for at least eight months, and appears to be still going strong. Our #1 malware detection this report was a TotalSecurity loader (W32/FakeAlert.LU) which was most active on August 8. Once executed, this “product” will gain control of the infected machine and lock out applications. When a user tries to launch any application (except for a web browser), a dialog box will pop up informing the user that the particular application they are trying to launch is infected and cannot execute. Of course, this is the whole ploy – the user is allowed to open the product page (through HTTP), where they may purchase a cleaning solution to reverse the TotalSecurity ransomware infection.

The developers of this ransomware are indeed hard at work creating code to keep their business alive. One indicator we observed this report was that the ransomware application had gone server-side polymorphic. This technique is typically seen with botnets (such as Waledac), and has been picked up by the developers of TotalSecurity. Initial infections typically start with an e-mail that have an attachment. As you can see from our highlighted spam e-mails, the templates and social engineering techniques are quite different yet contain the same ransomware loader. Once the loader is executed, it will connect to a server to download the ransomware product. This is where server-side polymorphism kicks in: the loader will connect to the same server and request the same file, yet download different code as it changes on an hourly basis. The ransomware product and function is the same, yet the code changes in an effort to avoid detection. This is an example of how relying purely on antivirus is not a silver-bullet approach to protecting systems from infection – since it’s the same website / URI, web content filtering can also assist in identifying the malicious site’s intent, while antispam can help flag the infectious e-mails in the first place.

The other notable infection floating around this month was ZBot, a do-it-yourself botnet kit that likely needs no introduction due to its high profile nature. Most of the ZBot variants we detect are different in nature, since they can each be configured to run their own botnets and target any information they desire. As an example this month, ZBot variants were noted to target US Military personnel. For more information on Zeus/ZBot, see our descriptive write-up here. Since it’s such a popular underground product, Zeus/ZBot continues to be developed in new versions with new features for future malicious use.

As previously mentioned, two of our highlighted spam campaigns were linked to malware prevalent in our top 10 listings. Two emails seen this report claim to have document attachments. In fact, they are zip archives with executables inside – clicking either one will lead to ransomware infection. A third infectious e-mail dug up a news headline over a year old about the Air France 447 crash that claimed hundreds of lives off the coast of Brazil. The e-mail claimed to have new photos of this crash – again, an attached zip file with an executable inside. These properties should be immediate red-flags to any user when opening such e-mails.

The attacks on the recent Windows Help Center vulnerability continued, propelling this threat to pole position in our top 10 attack list. The attack (CVE-2010-1885) is detected by FortiGuard Labs as ‘MS.Windows.Help.Center.Protocol.Malformed.Escape.Sequence‘. There was an exceptionally large spike in activity on this vulnerability on August 8th and 9th. As mentioned last report, exploitation of this attack can be rather potent since the vulnerability is not web browser specific.

DLL preloading attacks rely on a MS Windows system feature, which, in certain circumstances, can be abused to achieve escalation of privilege. Although the issue has been discussed in the security community for many years, we came up with some interesting insights which have not been discussed publicly before.

The paper presenting our findings is separated in three parts. The first part is an in-depth review of the issue. Nothing new here, but we thought a little reminder well layed out would not hurt. The second part analyzes seven typical mistakes in the development/QA process of popular applications that lead them to be vulnerable (seven case studies). Finally, the last part will feature ongoing research, addressing an interesting case study, in order to highlight the fact that DLL preloading can yield issues beyond what is generally admitted.

Because the seven case studies in the second part and the case study in the third part all feature zero-day vulnerabilities as of this writing, we are not able to release these two parts at this point, according to our responsible disclosure policies. The seven DLL preloading vulnerabilities have been reported to the vendors on July 16, 2010, and we are waiting for their patches. We started discussing this issue with MSRC (Microsoft Security Response Center) on May 20, 2010, as well.

Nonetheless, as the issue became widely-discussed in the security community and the media currently, we decided to release the first part. Of course, we will update our paper with more details (and insights) whenever the vendor’s patches for the case studies become available, and will make follow-up posts here as well. Stay tuned!

Meanwhile, you can download the first part of the paper here.

Guillaume Lovet contributed to this post.

However, fewer resources address the technical aspect of jailbreaking. You might have found out that the online jailbreaking tool is resorting to a drive-by-script exploiting a 0-day vulnerability. We’ll try and provide a few other technical findings below.

First, let’s connect to the site with a proper user-agent (i.e. iPhone’s Safari). It gives us a nice Javascript, whose interesting part is:

function get_page(){return model==null?null:("/_/"+model+"_"+firmware+".pdf"}

That is to say, the user is automatically redirected to a malicious pdf based on the model of the device and the firmware version.

As directory listing is enabled, we were able to list all the files in the corresponding repository:

The file “iPhone3,1_4.0.pdf”, for instance, features an encoded PDF Type1C font (Compressed Font Format) stream that looked suspicious enough for us to decode it (thanks to the excellent pdf-parser tool from Didier Stevens). In the now clear-text stream, we could identify at least one manifest (offset 0xbcd – see below) and an iOS executable (offset 0×1109, we will get back to it later on).

Note the large values for IOSurfaceBytesPerRow, IOSurfacePixelFormat, IOSurfaceHeight and IOSurfaceWidth in the manifest above.

The corresponding system API framework is basically not documented, but we can easily guess there is an allocation issue in an IOSurface object. As IOSurface objects run in kernel space, the process can bypass usual security restrictions.

It is highly likely this 0-day exploit can be used for other means than jailbreaking an iPhone/ iPod/ iPad. Consequently, Will Strafach wrote an iPhone application that detects suspicious PDFs and warns end-users when they are at risk.

As for the binary in the decoded PDF stream, essentially, it pilots the jailbreaking.
The executable starts by checking it can access /bin/bash or not via a BrowserController object (see figure below): if bash is accessible, it concludes the device is already jailbroken and recommends not to jailbreak it again. Otherwise, it considers the device is not jailbroken:

If the device is not jailbroken, the executable then downloads hxxp://jailbreakme.modmyi.com/wad.bin into a buffer of type NSMutableData, named wad (itself member of a class the author called “Dude”).
Before going any further, the executable checks that the downloaded version of the file wad.bin starts with the four bytes 0×42424242 (’BBBB’), then followed by its length.

The wad.bin file is exactly 3909273-byte long, i.e 0×3BA699. This length is stored in bytes 4, 5, 6 and 7:

$ hexdump -C wad.bin | head
00000000  42 42 42 42 99 a6 3b 00  15 b5 01 00 78 9c ec 7d  |BBBB..;.....x..}|
00000010  0d 9c 54 c5 95 ef bd dd  3d 43 33 34 70 81 46 87  |..T.....=C34p.F.|

This pattern may be used in the frame of counter-measures (eg: Snort signatures, etc…), to prevent jailbreaking from one’s network, for some reasons.
Additionally, it is worth noting a cookie keeps information regarding the jailbreaking attempts (date and time of access to jailbreakme.com, PDF file downloaded etc).

At this point, parts of the buffered wad.bin are dumped in inflated format on the device in /tmp/install.dylib. The dynamic library is then opened, and the do_install symbol is called. This is likely where the actual jailbreaking occurs.

Afterwards, the remaining XZ compressed data contained in wad.bin is then uncompressed, which can be reproduced manually (credits to Gecko_UK):

$ dd if=./wad.bin skip=111905 of=./wad.xz bs=1 count=3797368
$ 7zr x wad.xz
$ mv wad wad.tar
$ tar xvf wad.tar
...2009-04-27 16:34 Applications/
...2009-04-27 16:34 Applications/Cydia.app/
...2010-07-30 10:55 Applications/Cydia.app/commercial.png
...2010-08-01 20:52 Applications/Cydia.app/Modes/
...2009-08-09 11:55 Applications/Cydia.app/Modes/REMOVE.png
...2009-08-09 11:55 Applications/Cydia.app/Modes/INSTALL.png
...2010-08-01 20:52 Applications/Cydia.app/Modes/NEW_INSTALL.png -> INSTALL.png
...

And the jailbroken environment (Cydia applications, etc…) is installed on the device.

– the Crypto Girl (Axelle Apvrille) and the Vulnerability Guy (David Maciejak)

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.

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.

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.

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.