Some OS X Applications Vulnerable to MITM Attacks(vulnsec.com)
vulnsec.com
Some OS X Applications Vulnerable to MITM Attacks
https://vulnsec.com/2016/osx-apps-vulnerabilities/
14 comments
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.
I think the best we can do is to build honeypots and get an understanding of whether these vulnerabilities are actually being exploited.
find /Applications ~/Applications -name Sparkle.framework -exec plutil -extract SUFeedURL xml1 -o - {}/../../Info.plist \; | grep '<string>http://'These are vulnerable apps:
- colorschemer
- snippets
- colloquy
- macdown
- peppermint
- skim
- screenflow
- vagrant manager
- vlc
- monodraw
- yemuzip
Also: VLC, uTorrent, BitTorrent Sync, XQuartz, Sequel Pro, CotEditor (at least the versions installed on my Mac, should be the most recent)
Hopper, BackupLoupe, Transmission.
Mou, Pocket, Sequel Pro
also: Wekit Nightly, Dash
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:
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.
> 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>
<key>SUFeedURL</key>
<string>https://www.panic.com/updates/update.php</string>
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.
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?
- 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?
Just as a matter of efficiency...a recursive "grep" to hit every file in the tree is going to take far longer than it needs to. The "find" command knows how to be selective.
Try something like this:
Try something like this:
find /Applications -name '*.plist' -exec grep SUFeedURL {} +Better to alter the user defaults key SUFeedURL for an app than break its code signature by altering its info.plist file. Sparkle looks at the user defaults first anyway. Aside it's still not bullet proof because an app can override the feed URL programmatically. Another idea is just replacing the Sparkle framework inside an app with the latest version.
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?
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.
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.
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.
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.
The disappointing thing is that one of these issues was reported ~4 years ago: 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...
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...
List of vulnerable applications is here - https://github.com/sparkle-project/Sparkle/issues/717
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.
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.
I would consider it as 2 different vulnerabilities.
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/
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/...
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.
Things like this is why The Update Framework (TUF) Specification was created:
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/...
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.
[deleted]
Although Tunnelblick is named in the article, it uses Sparkle securely (https: always) and is not vulnerable to these attacks.
[deleted](1)
FYI, iTerm2 2.1.4 and 2.9.x are not vulnerable.
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".
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.
I bet if this were a Microsoft story, it would have been left alone.
[deleted]
Think of it this way. If I'm one of those agencies I ask myself the following:
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.