Fortinet today launched Security Minute, a new video threat landscape report that will be hosted by FortiGuard Labs threat researchers located around the world. Security Minute reports include up-to-the-minute threat news designed to help businesses protect their networks from  ever evolving cyber attacks.

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.

FortiGuard Labs’ August 2010 Threat Report has been posted. Below you will find an activity recap.

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.

A couple of months ago, we did research around the the DLL preloading issue (a.k.a “DLL-load” attack) that’s all over the news now.

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.

Unless you’re on a trek in the Himalayas, by now you’ve probably heard one way or another that the infamous “Jailbreakme” website is back to free iPhones (including iPhones 4 running iOS 4.0.1) and iPads : it’s just everywhere on the web, even with videos and tutorials.

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)