
Some OS X Applications Vulnerable to MITM Attacks - yakshaving_jgt
https://vulnsec.com/2016/osx-apps-vulnerabilities/
======
PhantomGremlin
Hat tip to the guy who discovered this, but I'm starting to think the
situation is hopeless. I'd bet that NSA, GCHQ, et. all already know about this
vulnerability and about countless others like it.

Think of it this way. If I'm one of those agencies I ask myself the following:

    
    
       What applications do people typically use?
    
       How do those applications typically interact
       with the Internet?
    
       How can we insert ourselves into that process to
       spy on people or to take control of their systems?
    

What if NSA devoted 10 people full time to looking for vulnerabilities like
this? What if they coordinated amongst the Five Eyes and, together, they had
50 full time people looking for vulnerabilities like this?

Could they afford to do it? Yes! Would they find a plethora of
vulnerabilities? Yes! So, are they doing it? Probably, what's to stop them
(other than legalities of course)?

It's low hanging fruit, compared to all the other, more esoteric stuff we know
they are already doing.

When history is written this will probably turn out to be the Golden Age of
governments spying on civilians. Robust crypto everywhere just can't happen
soon enough.

~~~
gurkendoktor
HTTPS is not going to stop the NSA or GCHQ, anyway.

I think the best we can do is to build honeypots and get an understanding of
whether these vulnerabilities are actually being exploited.

------
xucheng

      find /Applications ~/Applications -name Sparkle.framework -exec plutil -extract SUFeedURL xml1 -o - {}/../../Info.plist \; | grep '<string>http://'

~~~
jjude
These are vulnerable apps: \- colorschemer \- snippets \- colloquy \- macdown
\- peppermint \- skim \- screenflow \- vagrant manager \- vlc \- monodraw \-
yemuzip

~~~
misterdata
Also: VLC, uTorrent, BitTorrent Sync, XQuartz, Sequel Pro, CotEditor (at least
the versions installed on my Mac, should be the most recent)

------
snowwrestler
The article tells app maintainers that:

> To fix and avoid RCE in your app, you need to edit Info.plist file and
> replace http -> https for SUFeedURL key.

So to check for vulnerable apps I just grepped for SUFeedURL in my
Applications folder:

    
    
        snowwrestler$ grep -R SUFeedURL /Applications/*
        Binary file /Applications/Coda 2.app/Contents/Frameworks/Sparkle.framework/Sparkle matches
        Binary file /Applications/Coda 2.app/Contents/Frameworks/Sparkle.framework/Versions/A/Sparkle matches
        Binary file /Applications/Coda 2.app/Contents/Frameworks/Sparkle.framework/Versions/Current/Sparkle matches
        /Applications/Coda 2.app/Contents/Info.plist:	<key>SUFeedURL</key>
    

Then I looked in that Info.plist file and saw:

    
    
        <key>SUFeedURL</key>
        <string>https://www.panic.com/updates/update.php</string>
    

HTTPS, so I think I am good, right?

If I found HTTP strings I could protect myself by just setting them to HTTPS.
Either the app would update over HTTPS (if available), or the update mechanism
would just break. I'd have to manually check for updates though.

~~~
rorykoehler
Thanks for this. Vulnerable apps I found on my system:

\- Macdown \- Transmission \- XQuartz

2 of the apps I checked (Sequel Pro and Stuffit Expander) had empty plist
files which seems odd. Initially I thought I had maybe updated the software
and not opened it since so the file wasn't yet generated but in this case the
grep wouldn't have found a plist file at all. Do you know why they would be
empty?

------
jordanlev
What do I (as a user of some of these apps) actually do to avoid problems? I
noticed an update for Sequel Pro earlier today, and I went ahead and updated
it. But it seems that if the vulnerability is with the updater itself, then is
updating the apps using the potentially-mitm'ed updater a prudent thing to do?

~~~
retx
With this updating process when the update process itself is vulnerable is
"tricky", I know but you can avoid those nasty things by:

1) Using secure and let's say trusted VPN and then all your connections are
going to be encrypted by default 2) Update your applications in trusted
environment like your home network

There is only one thing to remember - don’t connect to public Wi-Fi Hotspots
unless you know what you do.

~~~
mikeash
A VPN will help, but it only encrypts your connections to the point where your
VPN is terminated, then it's off to the wider internet with no encryption.
Same, but worse, for your home network. MITM can be done in other ways than
hijacking connections on the LAN.

Note that the problem isn't just with the updater, but with the update
_checker_. That means that merely _running these apps_ makes you vulnerable,
if you've configured them to automatically check for updates (usually the
default). You don't have to actually update, just have an automatic check
performed.

To be safe from this, you'll want to disable automatic update checks in the
settings for each app. Of course, running the app to do this is dangerous, but
the odds of being targeted in this small window are low, especially if you
avoid easy targets like public WiFi while doing it. If you want to be
extremely paranoid, you can disconnect from the internet first. Once the app
makers publish updates, you can update out of band by downloading the new
version directly from their web site (over https, hopefully) and then you can
safely re-enable automatic update checking.

------
anon1385
The disappointing thing is that one of these issues was reported ~4 years ago:
[https://github.com/sparkle-
project/Sparkle/issues/169](https://github.com/sparkle-
project/Sparkle/issues/169)

I'm not sure why NSXMLNodeLoadExternalEntitiesSameOriginOnly was used instead
of NSXMLNodeLoadExternalEntitiesNever at the time[1]

I wonder if the hacky 10.6 code using NSXMLDocumentTidyXML was actually more
effective.

[1] [https://github.com/sparkle-
project/Sparkle/commit/b7dc2438a7...](https://github.com/sparkle-
project/Sparkle/commit/b7dc2438a7f9e1f1b79c2aba149e0509a6bba140)

------
retx
List of vulnerable applications is here - [https://github.com/sparkle-
project/Sparkle/issues/717](https://github.com/sparkle-
project/Sparkle/issues/717)

~~~
nobullet
Lots of apps in this list are there because they use Sparkle Framework. It
doesn't automatically mean that if an app uses Sparkle it is vulnerable. Each
must be checked for insecure HTTP requests. Sparkle is not the reason of the
vulnerabilities. Sparkle clearly states: use HTTPS.

~~~
retx
That's totally true but, WebView allows to execute unsafe handlers like
'file://', 'ftp://'. As a result in the worst case scenario when appcast
webserver was compromised then you don't need a private DSA key (which I
suppose is well protected on developers computers) to sign new binary, you can
just modify XML from appcast to get remote code execution on OSX computers
actually checking for an update. In short, from the website security flaw to
RCE on thousands of computers, or even more, then you don't need an active
MITM attack actually, think about it.

I would consider it as 2 different vulnerabilities.

~~~
pquerna
Right, the ability for an attacker to change an XML file like this could be
considered two separate issues.

Things like this is why The Update Framework (TUF) Specification was created:

[https://theupdateframework.github.io/](https://theupdateframework.github.io/)

The specification covers exactly this kind of attack and has signing of all of
the data about an update:

[https://github.com/theupdateframework/tuf/blob/develop/docs/...](https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-
spec.txt)

But, as far as I know, there isn't an implementation of TUF that works with
ObjectiveC and all the other parts of Sparkle, to actually update an OSX
application.

------
i-know
Although Tunnelblick is named in the article, it uses Sparkle securely (https:
always) and is not vulnerable to these attacks.

------
ancarda
Shouldn't this be covered by App Transport Security? Outbound HTTP connections
should be dropped, right?

~~~
retx
Only when application was compiled on OSX 10.11 El Capitan, it's not available
in previous versions.

------
gnachman
FYI, iTerm2 2.1.4 and 2.9.x are not vulnerable.

~~~
retx
Not affected by unsafe HTTP configuration but affected by Sparkle bug which
allows to exploit it in a case when XML file on the server was replaced since
it's not signed using DSA key. You can still exploit it without HTTP and MITM
"features".

------
gelasio
The original title to this article is completely accurate: "There's a lot of
vulnerable OS X applications out there."

I bet if this were a Microsoft story, it would have been left alone.

