Text console based, so it can run headless and/or in the background in a screen/tmux session.
(Given that the original post was about compromised downloads this is a bit ironic)
I run it on a really old low-power PC and it's been very nice...I can even access it remotely wherever I am.
http://www.macrumors.com/2016/03/07/transmission-malware-dow...
if [ -f "/Applications/Transmission.app/Contents/Resources/License.rtf" ] ||
[ -f "/Volumes/Transmission/Transmission.app/Contents/Resources/License.rtf" ] ||
[ -f "$HOME/Library/Application Support/com.apple.iCloud.sync.daemon/icloudsyncd" ] ||
[ -f "$HOME/Library/Application Support/com.apple.iCloud.sync.daemon/process.id" ] ||
[ -f "$HOME/Library/LaunchAgents/com.apple.iCloud.sync.daemon.plist" ] ||
[ -d "/Library/Application Support/com.apple.iCloud.sync.daemon/" ] ||
[ -f "$HOME/Library/LaunchAgents/com.geticloud.icloud.photo.plist" ];
then echo "OSX/Keydnap detected.";
else echo "You're good.";
fi
Source: https://gist.github.com/kaizensoze/ca96d039b295db220951d42ca...I didn't bother checking after I read that the autoupdate wasn't compromised, but never hurts to check - and I was not really going to do it until I saw your post.
pbpaste | sh - curl https://gist.githubusercontent.com/kaizensoze/ca96d039b295db220951d42ca7c83d89/raw/ | bashMight it be better to replace the first two tests with something like `-f /[star][star]/Transmission.app/Contents/Resources/License.rtf`?
Was the malware version also signed with an official Apple Developer ID? The same ID? Is a change of ID verified with the auto-updater?
If there was a malicious Developer ID, has it been revoked by Apple?
Anyone with a credit card can sign up for Apple's developer program and start signing apps.
[1] http://www.welivesecurity.com/2016/08/30/osxkeydnap-spreads-...
That's the terrible part about all of this. Having signed applications without any verification of the signer is pointless.
A simplistic, yet more secure approach, would be to have domain validated keys that could be used to sign applications. Browsers could then verify that the application downloaded from example.com was signed with a key for example.com. I think OSX already stores "This was downloaded from the scary internets!" in a separate resource fork so this info could go there as well. Maybe even cut out the middle mad and put them in DNS SRV records so you don't even need a central CA. If DNS gets compromised the client's have bigger problems already.
Unfortunately like all things like this, it'd be forever before it's widespread enough to be useful.
>> If your membership expires, users can still download, install, and run your Developer ID–signed applications. However, once your Developer ID certificate expires, you must be an Apple Developer Program member to get new Developer ID certificates to sign updates and new applications.
What I understand is that codesigning costs $99 a year, which open-source projects may want to skip, but this harms their credibility if their downloads are compromised.
If you always update as soon as possible, then you risk getting hit by a compromise like this one, or you could suffer other unintentional bad effects of a botched update.
But the longer you delay updating, the more you raise your risk of becoming a victim of a new vulnerability that's just been patched and is now in the wild.
I genuinely feel for the developers, and I personally would not blame them if I was affected, but unless the data was intercepted enroute from their server, then I think they have to accept some degree of responsibility for the whole delivery chain to the end user.
But, I don't wait a whole week if the update is from an organization which I think I can trust not to totally botch an update, because they're conscious of the enormous potential for costly legal liability. I'm thinking of organizations such as Microsoft, Apple, Nvidia, AMD, Google, as a few examples. I might wait 1 or 2 days in that case.
Instead of "Blah-blah, less than a day, go check yourself", they could grep the logs for IPs (and session cookies if they log that) of lucky winners and explicitly inform them, when they hit any page on their site. Then show generic version to everyone else. This takes all but 5 minutes to set up.
False negatives are pretty bad in this case, better for users to check themselves.
It will all remain exactly as it is now, except for the case when they recognize a visitor that is likely to have downloaded the malware. In this case they should throw an extra warning.
> The OSX/Keydnap backdoor is equipped with a mechanism to gather and exfiltrate passwords and keys stored in OS X’s keychain. The author simply took a proof-of-concept example available on Github called Keychaindump. It reads securityd’s memory and searches for the decryption key for the user’s keychain. This process is described in a paper by K. Lee and H. Koo. One of the reasons we think the source was taken directly from Github is that the function names in the source code are the same in the Keydnap malware.
Source: http://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malw...
https://news.ycombinator.com/item?id=12403906
In comparison to Windows, macOS doesn't really seem to show the developer in the normal user flow.
"The infected file was available for download somewhere between a few hours and less than a day."
https://twitter.com/objective_see/status/771189100355264512
Also, their other (free, open source) tools are very good too, like KnockKnock and RansomWhere:
Luckily, it was only the CLI version, which I was putting on an Ubuntu system...