Introduction
This post will present a simple method of performing a man
in the middle (MiTM) attack against Mac OS (Snow Leopard and OS X Lion) and its Software Update process. The software update is done via clear
text HTTP leaving it vulnerable to attacks such as the one described in this
paper. Funny thing is that a previously disclosed vulnerability
Note: OS X Mountain Lion utilizes the App Store application for Software updates. The application makes use of HTTPS plus other SSL/TLS methods to guarantee the authenticity of the data coming back from the servers. After all my failed attempts, it appears that it does validate the authenticity of the certificate presented by the server.
CVE-2013-0973
Note: OS X Mountain Lion utilizes the App Store application for Software updates. The application makes use of HTTPS plus other SSL/TLS methods to guarantee the authenticity of the data coming back from the servers. After all my failed attempts, it appears that it does validate the authenticity of the certificate presented by the server.
CVE-2013-0973
Software Update Process
When the software update application runs it starts by
executing a GET HTTP/1.1 request to Apple’s update server (http://swscan.apple.com/content/catalogs/others/index-lion-snowleopard-leopard.merged-1.sucatalog.gz)
and request the update catalog. This catalog contains all the updates that have
been released by Apple after a certain date (described in the catalog file).
Each update includes a collection of URLs, these URLs are for the distribution
file, installation package file, and package description files.
The software update application reads all these updates and
compares to what it has stored in Cache
($HOME/Library/Caches/com.apple.SoftwareUpdate/Cache.db) and attempt to
download the distribution files for those updates that are new (not in the
cache). The distribution file contains all the information regarding the
package. It also includes some Installer JavaScript (http://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/InstallerJavaScriptRef/InstallerJavaScriptRef.pdf)
with some defined functions that decide whether the update should be displayed
at the end and if it needs to be installed (More on this later).
After the software update application has finished reading
all the packages, it then presents the user with the results (Shows a window
saying there are new updates to be installed). When the user selects each
update, there is a description at the bottom that shows information regarding
the update (More on this later).
Exploiting
Intercepting the traffic was a piece of cake, with the use
of ARPSpoof, IPTables redirect and a little Python script that I wrote, I was
able to intercept the traffic and replace the content (returned to Software
Update application) with custome URLs. The Python script replaces the URL for
the installation package, URL of distribution file and changes the post date
and version of the update catalog (to force updates to appear).
Once I was able to intercept the traffic and inject custom data, my previously "No updates found" Software Update process turned into "Oh wow, there is an update"
The first file I took a swing at was the distribution file.
The distribution file also allows the option of running custom commands on the
host by enabling the allow-external-scripts option in the <options/>
element of the distribution. But after taking a close look at the Software
Update application, I ran into this:
In the evaluateProduct method of the application, there is a
check to see if the allow-external-scripts attribute has been enabled. If it
has, the application discards the package and logs a “Insecure distribution
script from %s” error message where %s is the URL it downloaded the
distribution from. This was a result of the APPLE-SA-2007-12-17 security update released by Apple.
I tried encoding the attribute and its value in different
ways but it appears that the Software Update application waits until all the
XML entities have been resolved and evaluated and then it checks for the value of
the attribute. So that is a no go there.
Replacing the Installation Package
Without touching anything in the distribution, my Python
script will replace the URL of the installation package with whatever you
specify in the parameter. Thinking I could just replace the installation
package and exploit users this way, I went ahead and tried it. After multiple
attempts, I always kept seeing the same error when OS X attempted to install
the package. The console application would show a log entry stating that my
custom package was not trusted. It turns out Apple has done an excellent job at
making sure that the installation packages of updates are only signed by Apple.
I even attempted using a package that was signed with my OS X Developer ID
certificate (used to deploy to the App Store). So this was a nother no go.
Then it hit me!
So after almost giving up, it dawned upon me that the
description shown by the Software Update application is composed by custom HTML
data specified in the distribution file.
So at the very least, I was able to modify this HTML to include a custom
link to the description of the package.
But I thought this was a bit lame and decided to use a more
sophisticated approach. Then it hit me, how about I use a combination of SET
and Metasploit to obtain shell? Well, as it turns out SET (Social Engineering
Toolkit) has an entire module of web based attacks.
Selecting the website attack vectors, I decided to go ahead
and choose the Java Applet attack vector.
Using the signed applet attack, I was able to select the
Windows meterpreter payload. Good thing SET also automatically generates Linux
and OS X reverse TCP shell payloads.
Since I was serving the distribution package by
an already running instance of Apache, I decided to change the SET web port to
8019. With this in mind, I modified the package’s description (HTML) and added
a visible (during a real attack it would be invisible) IFrame that uses the
attack URL (http://192.168.1.15:8019, in
my running example) as the source.
Good thing the Software Update application makes full use of
the WebHTMLView class to display the description. This means that any applets
or embedded objects (ROFL) are processed.
Once the user selects the package and the description is
shown, the victim will see the Java warning.
Of course, during a real attack, an attacker would use an
Applet that was signed by a certificate that points back to Apple somehow (fake
information?)
Once the victim clicks on ‘Run’, it is all game over.
And that can only mean one thing….
BOOM! Goes the dynamite!
Updates
I wrote a Metasploit module (called software_update2.rb) that I still have not pushed for addition. If you would like a copy of it, please hit me up via Twitter @eaescob.
On 03/14/13 Apple released the security announcement, Apple's fix only fixes the executable code portion of the vulnerability. The fact is that Software Update still runs via HTTP and package descriptions can still be modified.
Updates
I wrote a Metasploit module (called software_update2.rb) that I still have not pushed for addition. If you would like a copy of it, please hit me up via Twitter @eaescob.
On 03/14/13 Apple released the security announcement, Apple's fix only fixes the executable code portion of the vulnerability. The fact is that Software Update still runs via HTTP and package descriptions can still be modified.
Timeline
10/30/12 - Sent email to product-security@apple.com reporting the issue and attached a PDF paper.
10/30/12 - Apple accepted the entry and is investigating the issue.
03/14/13 - Apple released the security announcement.
10/30/12 - Apple accepted the entry and is investigating the issue.
03/14/13 - Apple released the security announcement.
