Yet another OS X security issue.

In the last two weeks, we’ve had Leap.A, Inqtana.A and now a vulnerability with the way that Apple’s web browser Safari, and it’s mail application Mail.app handle the opening and executing of certain file types by default. This issue is mainly concerned with the opening of .zip files on OS X, and the malicious possibilities are endless on this one.

This vulnerability has been discovered by Michael Lehn The culprit of this vulnerability is in the default configuration of Apple’s Safari web browser. In it’s default configuration the option to “Open ‘safe’ files after downloading” is enabled. The function of this option is to automatically display, documents, spreadsheets, movies and images as soon as they are downloaded to the users computer, by opening them with the application associated with the file type.

The vulnerability comes into play when you store a shell script in a ZIP archive without including the ‘shebang line’ (#!/bin/bash) in the shell script. As soon as you omit the ‘shebang line’, Safari will no longer recognise the script as potentially dangerous content, and executes the shell script without any confirmation needed by the user.

The shell script will get executed within the Terminal.app by a shell. If the user has configured Finder to open scripts using Terminal.app, this will happen automatically, without any intervention on the users part. If you give the script an extension, such as “jpg” or “mov” and then store it within a ZIP archive, OS X will add a binary metadata file to the archive which determines the files association. What this metafile does is instruct the operating system on any other Mac to open that file with Terminal.app — regardless of the extension or the symbol displayed in Finder. The terminal will then re-direct scripts without an interpreter line directly to bash, the standard UNIX shell in OS X.

The immediate action that OS X users should be taking against this right now is to deactivate the “Open ‘safe’ files after downloading” option in the Safari preferences pane. An additional security measure is to move the Terminal.app from /Applications/Utilities into a different folder altogether, this is because the metadata file within the ZIP archive always contains the absolute path to the application to be used to open/execute the file. The only issue with doing this is that when you apply security patches/system updates to OS X, the application must be moved back into it’s original location, otherwise it could cause problems in applying the updates.

To determine if you are vulnerable Heise Security have a safe online demonstration available here. This demo attempts to open Terminal.app to display the contents of a folder. If you are running OS X in it’s default configuration and use Safari, the window will open without waiting for a prompt from the user. The possibilities of what this script could do are endless, and I am going to leave that part to everyone’s imagination. Feel free to submit comments on the worst possible thing you could do with shell script running under the currently logged on user running Safari ;-)

Share

Inqtana.A – The OS X Bluetooth Worm

Times are getting interesting for OS X users out there, first we have news of Leap.A, the OS X virus that’s currently doing the rounds, and now we have Inqtana.A, an OS X bluetooth proof-of-concept worm for OS X 10.4 (Tiger).

Inqtana.A has not yet been been seen in the wild, but it is recommended that you install the latest security patches from Apple just to make sure that you’re covered in case this turns into more than just a proof-of-concept. Inqtana.A uses Bluetooth library and this expires on the 24th February, so it is unlikely that this will be seen in the wild in it’s current form, but the PoC is there now, and this leaves opening’s for someone to make use of it.

The CVE number for this worm is CVE-2005-1333
Inqtana.A arrives to victims systems as an OBEX Push request, and the user will be prompted to accept the data transfer. If the user accepts the data transfer Inqtana.A will then use a directory traversal exploit to copy it’s files that so it starts up automatically upon the next reboot. Once the system has been rebooted and Inqtana.A has been activated it will then look for any devices that accept OBEX Push requests and try to copy itself to those devices in the same manner.

Inqtana.A tries to copy 3 files via bluetooth to replicate, the files are:
w0rm-support.tgz – The worm components
com.openbundle.plist – Needed for automatic startup after reboot
om.pwned.plist – Needed for automatic startup after reboot

To remove the worm from your system:
- Apply the latest security patches from Apple
- Remove the following files from your system:
– /Users/w0rm-support.tgz
– /Users/InqTest.class
– /Users/com.openbundle.plist
– /Users/com.pwned.plist
– /Users/libavetanaBT.jnilib
– /Users/javax
– /Users/de
– /Users/[user name]/Library/LaunchAgents/com.pwned.plist
-/Users/[user name]/Library/LaunchAgents/com.openbundle.plist

Thanks once again to the guys at F-Secure for all the info on this one.
It really seems like things are hotting up on the OS X front these days, which could be a good thing, as Apple has always been someone quiet on security patches and exactly what they fix, maybe this will cause them to give a bit more disclosure on the subject. OS X has a reputation for being secure, and it’s one of Apple’s marketing messages, so to keep that Apple are really going to have a lot of work to do on the security front if things start kicking off.

Share

Leap.A, The OS X Virus

I’ve been following the news on this one since it started on macrumors.com, and now F-Secure have classed this one as a virus. The file in question is named “latestpics.tgz”, and when it was initially posted is was advertised as being pictures of the upcoming “Mac OS X Leopard”, also known as “OS X 10.5″.

You can’t simply just get infected with this virus, there are certain things that you have to do for this to infect your Mac. Which is still a worry as a lot of people will be really interested in seeing the pictures of the new OS X, and will undoubtedly go through the following steps needed to infect you beloved Mac. If you somehow come across this file which either got sent to you via e-mail, ichat or you found somewhere to download it. DO NOT, perform these steps, otherwise you will become infected!

- Double-click on the file to decompress it
- Double-click on the resulting file to “open” it

If you are running as a non-admin user even if you do go the steps above, it will still infect some files, not as badly though as if you are running as an admin user OS X, as this needs to have admin rights to be able to infect certain files.

This is a brilliant attempt at social engineering more than anything, as the virus is not capable of self propagating at all, it relies solely on users actually going through the steps mentioned above. Another important note is that there is a bug in the code that prevents this virus from working as it was properly intended to do, which is good for anyone running OS X, but bad in the sense that it will stop certain applications from launching once you are infected. This virus does not exploit any security holes in OS X at all, as I mentioned above it purely relies on the user trying to see what’s in the compressed file.

A brief rundown on the contents of the file:

Once the file has been unzipped, tar will let you know that there are 2 files contained within, namely:
._latestpics
latestpics

The .latestpics file is actually the resource fork of the file, which has had it’s icon changed to reflect it as a jpeg file, therefore fooling users in to trying to open this file. The following from Andrew Welch gives a really decent breakdown on what exactly the virus does:

“1) It copies itself to /tmp as “latestpics”
2) It recreates its resource fork in /tmp (with the custom icon in it) from an internally stored gzip’d copy, then sets custom icon bit for the new file in /tmp
3) It then tar + gzips itself so a pristine copy of itself in .tgz format is left in /tmp
4) It renames itself from “latestpics.tar.gz” to “latestpics.tgz” then deletes the copied “latestpics” executable from /tmp

–This gives it a pristine copy of itself, for later transmission.–

5) It extracts an Input Manager called “apphook.bundle” that is embedded in the macho executable, and copies it to /tmp
6a) If your uid = 0 (you’re root), it creates /Library/InputManagers/ , deletes any existing “apphook” bundle in that folder, and copies “apphook” from /tmp to that folder
6b) If your uid != 0 (you’re not root), it creates ~/Library/InputManagers/ , deletes any existing “apphook” bundle in that folder, and copies “apphook” from /tmp to that folder
7) When any application is launched, MacOS X loads the newly installed “apphook” Input Manager automatically into its address space

–This allows it to have the code in the “apphook.bundle” injected into any subsequently launched application via the InputManager mechanism–

8a) When an application is subsequently launched, the “apphook.bundle” Input Manager then appears to try to send the pristine “latestpics.tgz” file in /tmp to people on your buddy list via iChat (who will then presumably download the file, double-click on it, and the cycle repeats).

8b) (It looks like the author intended to get it to send the “latestpics.tgz” file out via eMail as well, but never got around to writing that code)

–This lets it send itself to people on your buddy list via iChat; this appears to be the only way it self-propagates externally–

9) It then uses Spotlight to find the 4 most recently used applications on your machine that are not owned by root
10) In an apparent “Charlie and the Chocolate Factory” reference, it then checks to see if the xattr ‘oompa’ of the application executable is > 0… if so, it bails out, to prevent it from re-infecting an already infected application
11) If not, it sets the xattr ‘oompa’ of the application executable to be ‘loompa’ (this does nothing, it is just a marker that it has infected this app)
12) It then copies the application executable to its own resource fork, and replaces the application executable with the OSX/Oomp-A trojan

nb: If run via double-clicking on the file, and the user doesn’t have privileges to modify an application, it silently fails. If run via the command line, it will ask for the admin password if it encounters an application for which it doesn’t have privileges to modify.

–It has thus effectively injected its code in the host application–

13) When an infected application is launched from then on, the trojan code is executed, and it tries to re-infect and re-propagate itself to other applications
14) It then does an execv on the resource fork of the executable, which is the original application, so the application launches as it normally would (in theory… see below)
15) Due to a bug in it’s code for executing the original app from it’s resource fork, it is only allocating a buffer 4 bytes bigger than the path when appending “/..namedfork/rsrc” to the path, it will stop any app it infects from running. Instead of adding the length of the string, it errantly adds the length of the pointer to the string, which is always 4 bytes.

In the end, it doesn’t appear to actually do anything other than try to propagate itself via iChat, and unintentionally prevent infected applications from running.”

Here
is a disassembly of the executable if you’re interested, this is only the main executable portion of the code, not the embedded “apphook” InputManager code.

  • Share

    Cracking WEP with KisMac

    Granted this is only done against a 40-bit WEP key, so that would explain why it only takes 10 minutes to obtain the WEP key, but this is still pretty good going either way. Plus you don’t have to keep changing tools to eventually obtain the WEP key.

    The video is a bit blurry, but if you’ve got a Mac and have KisMac installed, it’s really not difficult to make out what’s going on at all.

    Really worthwhile watch!!

    http://www.ethicalhack.org/videos.php

    Share

    OS X As A Pentesting OS

    Apple’s OS X has been recieving a lot of flack lately, both in regard to security issues and as it’s worth as an OS. I used to be a long time Linux/BSD user, until one day I found an 12′ Apple Powerbook lying around. After playing around on it for a week or so, I really began to see the possibilities, which lead me to go and buy my own 15′ Powerbool and to see if this could replace my aging Dell laptop which was currently dual booting Debian and OpenBSD. As OS X is built on a FreeBSD microkernel, it has all the BSD bits under the hood, so I wanted to see how far I could push this baby, and see if I could end up using a Mac for my daily pen-testing work, and have a rock solid secure operating system to work on at the same time? The answer is a huge yes!

    OS X may have it’s faults, but it is a damn site more secure than Windows, but then again, that doesn’t really take too much now does it? It ships with a built in firewall, which is the standard FreeBSD IPFW (IP Firewall),this really is an great firewall, and in my opinion blows the likes of IPchains/IPtables on Linux out of the water. It’s a lot easier to configure, and has a hell of a lot more options. I won’t argue that the interface that Apple gives you is really basic, and consists of options like, enable/disable SSH, SMB, VNC, etc, and whether or not you want logging turned on or off. As a security professional, and a UNIX geek, this really isn’t good enough at all, so we need to drop under the hood and really modify these rules to suit our everyday needs, and only allow the things in and out that we really want to, and to have some fun we’ll set it so certain rules only kick in at certain times of the day (using cron) or when our laptop is getting scanned/probed (portsentry). For info on how to lock down IPFW on OS X either read the IPFW man page (best way), or have a look at these links, as they will give you the basics:

    http://www.novajo.ca/firewall.html

    http://www.ibiblio.org/macsupport/ipfw/

    http://www.macdevcenter.com/pub/a/mac/2005/03/15/firewall.html

    Great! So now we’re got the firewall on our shiny new Mac configured, and we can move on to other things, before we start adding a load of tools and the like. OS X comes with a great utility called FileVault, what this little baby does is encrypt your entire home folder and everything in it with 128-bit AES encryption. The encryption and decryption happens in real time, and when you turn it on, there really isn’t any performance hit at all. So now we have a OS that after the few minutes we just spent tweaking it, is already a hell of a lot more secure than most other OS’s.

    Now OS X has a load of cool applications already developed for it, especially for anything media related, but we’re not going to go down that route. We want a pen-testing box to play with. First things first, if you’ve ever used Free/Open/Net BSD or Debian/Gentoo Linux then you’re going to know how useful the ports and package collections are. OS X doesn’t ship with any form of ports collection, but you can just install one, and away you go. Currently you get two different ports trees for OS X Fink (http://fink.sourceforge.net/) and Darwin Ports (http://darwinports.opendarwin.org/), my personal favourite is Darwin ports, as it has a lot more security related ports. So get that installed, all the installation instructions are on the Darwin ports site, and it’s a pretty painless install.

    Now on to adding some tools on our little beast, the tools that I most frequently used on Linux/BSD are listed below, all the ones with * next to them are able to be installed on OS X, most of them through the Darwin ports tree.

    Ethereal*
    Cryptcat* (OS X has NetCat installed by default)
    Tcpdump*
    Dsniff*
    Nmap*
    Metasploit Framework*
    Perl (Installed by default)
    Python*
    X11*
    THC-Hydra*
    Nessus*
    Kismit*
    Snort*
    Ettercap*
    Hping2*
    John*
    Nikto*
    NBTscan*
    Ngrep*
    Stunnel*
    THC-Amap*
    Ntop*
    Nemesis*
    Paros*
    Web Scarab*

    So as you can see, I managed to get everything that I was using on Linux and BSD installed, I also have a load of other tools installed, but the ones listed above are the more popular tools. If you can install anything on BSD then it should be taken as a given that you’ll be able to install it on OS X (it may require a bit of extra work, but usually nothing major.) This does include window managers as well, as I’ve had Fluxbox and KDE running.

    When it comes to wireless tools, you really can’t go wrong with KisMac, it’s a clone of Kismet, but yet is does a hell of a lot more than Kismet, for instance it has built in WEP cracking, which really is a nice added plus. I know that this sort of thing is planned for the next big release of Kismet, but still, on OS X it’s here now. One thing here though, you need to have a Powerbook to be able to use KisMac as the standard Apple airport card currently can’t do passive sniffing, and the Powerbooks are the only Macs with a PCMCIA slot. If your wireless PCMCIA card isn’t supported head over to http://wirelessdriver.sourceforge.net/ and see if there’s a driver listed for your card there. Wirelessdriver works like a charm for my Orinoco and Prism cards.

    There’s also MacStumbler and iStumbler which are pretty much like NetStumbler, never been a great fan of NetStumbler, but useful for a quick look around.

    Well that’s about it, but I’d seriously recommend a Mac with OS X for pen-testing, mine hasn’t let me down yet.

    Share

    Old and Known

    Here is a very old and known issue with Mac: Too many ways to bypass authentications and too few fixes.

    A week ago, a person emailed us (SecuriTeam) about another bypassing issue in Mac OS X Tiger (10.4 family).

    The person told us that he was able to change the root password (because he couldn’t remembered it) using the Netinfo program.

    Sounds ok… on any *nix I can change the root password. All I need is to become a sudoer, or become root some other way, without necessarily knowing the root password.

    But here, the person did not have any special privileges, as far as I could understand, and still he was able to change the ROOT password.

    I don’t have a Mac to test this issue on :( so searching SecuriTeam and using google I was able to find that this issue was known even before Mac OS X. That is, Mac users could bypass user access restrictions. There was an unofficial patch to fix this issue, and theoretically, Apple fixed this for Tiger as well.

    But this person claims that his system is up to date, and that he can still bypass any root based authentication in order to change the password.

    There is no reason to publish this as news in SecuriTeam, because this is a known issue that was reported back in 2001 by us. Repeating the same story where the only change is that it works with newer versions is useless, so I decided to blog it instead.

    I really hope that Apple fixes this issue once and for all, but then again, thats why I prefer open source products. If the vendor does not fix the problem, I can always find a way to fix it, at least for myself…

    Share

    Band Assists Fans in Ripping Their CD

    The music band Switchfoot has posted in their forum a guide to ripping their newly released music CD.

    The most interesting aspects of their guide is this sentence:
    my heart is heavy with this whole copy-protection thing. Many PC users have posted problems that they have had importing the new songs (regular disc only, not the dual disc) into programs such as Itunes. Let me first say that as a musician AND as a music fan, I agree with the frustration that has been expressed.

    Moreover they state that:
    We were horrified when we first heard about the new copy-protection policy that is being implemented by most major labels, including Sony (ours), and immediately looked into all of our options for removing this from our new album.

    Which is very interesting when it comes from a band whose – ideally – sole purpose is to sell CDs.

    Highlights from the guide:
    1) MacOS users have no problem “Ripping” the CD i.e. importing it to iTunes

    2) Windows users that “accidentallyhaven’t installed the copy protection program, can use a program called CDEX to rip the CD’s tracks

    3) Windows users that “accidentallyhave installed the the copy protection program, will first need to save the songs into Microsoft’s WMV copyrighted/protected format, then burn the WMV files to an Audio CD. Once this has been completed they can then rip back to unprotected WAV files

    Share

    Is that an OS X in your PC or are you just happy to see me?

    In my previous post I discussed how Apple has placed a TPM device in their computer to try and make it difficult to install their Tiger operating system on “normal” (i.e. non-Apple) Intel based computer. It appears that Justin Nolan has been able to get around this and has placed a HOW-TO guide in the following URL: http://www.360hacker.net/forums/viewtopic.php?t=158, hooray for him :) , in any case, you can probably save yourself the time and buy (or get a free) mini-Mac bundled with Tiger (Mac OS X).

    Share

    Apple PC Gets a DRM Chip

    Apple has decided to prevent people from downloading their operating system from the Internet (of course pirated) and running it on a non-Apple Intel based PC.

    To achieve this Apple has placed a Trusted Platform Module made by Infineon Technologies inside their upcoming Intel based computers.

    This makes two firsts, as far as I know:
    1) The commercial use of a TPM
    2) The use of such a module to prevent the installation of an operating system

    You can learn more about this from this link.

    Share