
Transmission BitTorrent Client OSX/Keydnap Malware Incident Q+A - tomasandrle
https://transmissionbt.com/keydnap_qa/
======
okket
Simple file check if you are infected:

    
    
      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...](https://gist.github.com/kaizensoze/ca96d039b295db220951d42ca7c83d89)

~~~
toxik
And to run it from the clipboard:

    
    
        pbpaste | sh -

~~~
labster
Why not this?

    
    
        curl https://gist.githubusercontent.com/kaizensoze/ca96d039b295db220951d42ca7c83d89/raw/ | bash

~~~
okket
Your line downloads and executes the latest version of the gist, it could have
changed from a file check to a virus installer by the author (unlikely, but I
have to point it out). To be a bit more safe (while trusting that GitHub is
not compromised) pin a known, verified version:

    
    
      curl https://gist.githubusercontent.com/kaizensoze/ca96d039b295db220951d42ca7c83d89/raw/a26e5a025ea21d3a0af536eeca49619272d0068f/quick-osx-keydnap-check | bash
    

(sorry for the overlong line)

~~~
heeen2
this pattern is just as dangerous (maybe less for github if you trust them)
because you can detect curl and deliver malicious code:
[https://www.idontplaydarts.com/2016/04/detecting-curl-
pipe-b...](https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-
server-side/)

~~~
okket
> this pattern is just as dangerous

As a general pattern, please do not do this. In this specific case I think
most people trust the service (GitHub) and their DNS recursor + SSL library.
Attacking these is not on the level of "random drive-by phishing", more like
"targeted high value state sponsored".

To avoid this discussion I did not include the curl version in my original
posting.

------
dantiberian
They never responded with details of what they were doing to improve security
after the last incident:
[https://forum.transmissionbt.com/viewtopic.php?f=1&t=17938](https://forum.transmissionbt.com/viewtopic.php?f=1&t=17938).
The outside appearance is that they didn't address the problem seriously
enough.

~~~
jrochkind1
Yeah, I was thinking, didn't this happen before?

~~~
lqdc13
One of their servers or dev machines might have a rootkit. At this point,
wiping basically everything is required.

------
davej
Second time that this has happened to Transmission this year. Last time a
ransomware got included. If you're a Transmission user then be _very_ cautious
when installing new versions.

~~~
simcop2387
Main reason that I only install stuff like this from my distro's repositories.
Anyone know if this would have affected homebrew and such on OSX?

~~~
jquast
Homebrew packages verify checksums, so very unlikely to be affected.

~~~
jrochkind1
And where do the checksums come from?

~~~
jquast
Changes made by GitHub pull requests. I'm sure an anonymous contributor who
submits only a checksum change, without version bump, would most certainly
fail review.

~~~
jrochkind1
I don't believe that's true.

I'm googling to try to find how Homebrew uses checksums and where it gets
them. But not everything homebrew installs comes from GitHub, so I don't see
how checksums for all of it could come from 'Changes made by GitHub pull
requests'.

And it looks like homebrew checksums both source packages and pre-compiled
binaries. There's no way an upstream dependency would be providing their own
checksum for a homebrew compiled binary. Homebrew also switched from using MD5
to using SHA1 recently
([https://github.com/Homebrew/brew/blob/master/share/doc/homeb...](https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Checksum_Deprecation.md)),
obviously all of their dependencies didn't switch in unison too, which
suggests the checksums do not come from the dependencies themselves.

Looking for more info about this, having trouble finding it. To have
confidence in homebrew's checksum system, one needs to know how it works and
where they come from, but having trouble finding it.

Or did you mean the checksum is made in a PR to homebrew's own repo? Right,
but the question is still where it comes from. If it was generated from bad
source obtained from upstream, it will of course be bad. It's just verifying
that the package as installed matches what homebrew maintainers meant to
install; but that's no guarantee that what homebrew maintainers meant to
install wasn't bad in the first place. Since transmission was distribution bad
packages itself due to a hack, I'm not following how homebrew providing a
checksum means that it can't re-distribute bad packages from upstream. It does
mean that homebrew itself is harder to hack than transmission, but doesn't
necessarily help when transmission is hacked.

------
kalleboo
So what happened with the codesigning? That's pretty much the only viable line
of defense for the average user (nobody is going to be verifying SHA
signatures, or the site is going to be compromised along with the download)

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?

~~~
andreasley
According to this article [1], the compromised app was indeed signed – but
with a different Developer ID than usual.

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-...](http://www.welivesecurity.com/2016/08/30/osxkeydnap-spreads-via-
signed-transmission-application/)

~~~
koolba
> According to this article [1], the compromised app was indeed signed – but
> with a different Developer ID than usual.

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.

~~~
dantiberian
It's not completely pointless, as it allows Apple to (silently and quickly)
release updates which distrust that Developer ID, however a stronger
protection would be to pin apps to a particular Developer ID.

------
rahiel
It's nasty that a free software project has to deal with this, given their
limited resources. This shows the importance of reproducible builds and using
package managers with verification like APT or homebrew.

------
Mahn
More info on the malware:

> 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...](http://www.welivesecurity.com/2016/07/06/new-osxkeydnap-malware-
hungry-credentials/)

~~~
aparadja
Wow. I'm the author of keychaindump. Didn't expect to become a malware co-
author.

~~~
robk
Seemed pretty likely though don't you think?

~~~
aparadja
I guess any security tools and scripts are bound to be used for naughty stuff
at some point, but I thought "real" malware writers would put more effort (at
least obfuscation) into their products. Keychaindump is a crude hacky PoC, and
I honestly didn't expect it to get directly copy-pasted into "serious"
malware.

~~~
sitkack
Evolution doesn't work hard for no reason.

------
FatalLogic
I'm not a Transmission user, but this makes me wonder, as a sort of Ask HN
question: How long do you wait before updating software?

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.

~~~
okket
Neither during this or the previous incidence the updates were compromised
(they were checked by the installed binary). Only fresh downloads from the
website.

~~~
FatalLogic
I haven't read much about this, so perhaps I'm not understanding clearly, but
if the downloaded binary from Transmission's "website server" was replaced,
then how is that not a compromise?

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.

~~~
dragandj
Well, they do accept some kind of responsibility: it is spelled out clearly in
the license what they accept, and you can choose whether you prefer the terms
defined in GPL, or MIT (Transmission is dual-licensed).

~~~
FatalLogic
Do you mind linking to that? Please quote the relevant part of license if you
have time.

I ask that because I think they'd be insane to accept responsibility.

I searched on their site, briefly, but I couldn't find this.

I haven't checked MIT license but the GPL 3.0 has got this clause about
liability limitation.

16\. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY
COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM
AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL,
SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR
DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR
A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH
HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

To me it sounds like it means whatever happens after you use our software,
it's not our fault! Which sounds like a reasonable license for open source
free software, to me.

~~~
dragandj
Exactly that. They give you their work for free (as in freedom and also as in
beer), so why would they accept anthing more than a responsibility to provide
you with the source and wish you a good luck? If you want protection, you can
buy commercial support for a GPL-licensed software, if it exists for the
software in question, or look for an insurance company to buy insurance
against any calamity. Why would Transmission developers provide such thing,
and what's more, for free?

------
SturgeonsLaw
That's not the first time this has happened... [http://gizmodo.com/yes-
ransomware-can-affect-macs-too-176323...](http://gizmodo.com/yes-ransomware-
can-affect-macs-too-1763239644)

------
okket
Service announcement: You were only at risk when you downloaded fresh copies
from the website. As with the previous incident, updates within the app were
safe and checked.

~~~
xnyhps
It's pretty scary that they still haven't fixed the Sparkle RCE vulnerability
from a few months back. Attackers with access to their servers could've
installed malware for every user, even if they didn't install the update.

------
yladiz
Kinda sucks, and I haven't followed Transmission for a while, but them
transitioning more to Github is a good thing -- I trust Github more than a
self hosted solution, in general. It sucks they've been compromised twice in a
year, but hopefully this will help mitigate some of that.

------
Veen
I like Transmission, but this is the second serious security problem they've
had this year. Once you can forgive, but twice and it's time to look for a new
BitTorrent client.

~~~
okket
FYI: Transmission binaries are now hosted on GitHub, so it is very unlikely
that anything like this can happen in the future without compromising
developer machines.

~~~
lucb1e
Question is, how implausible do we think it is that a developer's computer
gets compromised?

~~~
fastball
Well, a developer's local machine will typically be much less likely to be
compromised than a always-on, publicly-broadcasted machine.

------
aorth
You might want to install Objective-See's free BlockBlock tool to block these
type of things:

[https://twitter.com/objective_see/status/771189100355264512](https://twitter.com/objective_see/status/771189100355264512)

Also, their other (free, open source) tools are very good too, like KnockKnock
and RansomWhere:

[https://objective-see.com/](https://objective-see.com/)

------
huhtenberg
> Am I at risk?

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.

~~~
jmiserez
Nice idea with a major problem: If they did this, the absence of such a
message could suggest that you were not affected, when in fact you could be
(changed IP, cleared browser, etc).

False negatives are pretty bad in this case, better for users to check
themselves.

~~~
huhtenberg
No, you are missing the point.

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.

~~~
jmiserez
You would be right if nobody besides the affected people would ever know that
they are doing this.

But as soon as other people know or hear of it, they will go check the website
to "see if they are affected". Even if the website has a huge disclaimer
telling people that they could still be affected, the absence of the warning
would still suggest that they are not affected, even when they could be.

------
mirap
This is happening too often... so, what other BitTorrent clients are you using
on Mac OS?

------
deep_attention
Are there any good alternatives to Transmission on OS X?

~~~
pwg
RTorrent [https://pmukhanov.wordpress.com/2014/01/19/installing-
rtorre...](https://pmukhanov.wordpress.com/2014/01/19/installing-rtorrent-on-
mac-os-x/)

Text console based, so it can run headless and/or in the background in a
screen/tmux session.

~~~
diyorgasms
I've been using rtorrent for years and I wouldn't ever suggest anything else.
It's just so damn simple and reliable. I love the concept of watch directories
too. Upload a torrent file to a specific directory, and the data will be
downloaded to a specific directory. You can have multiple watch directories
for different types of data.

------
varcharlie
They say that the infected file was only there for a day, but maybe it would
behoove them to do some bash-fu w/ their logs and get an approximation of the
number of users affected!

------
fastball
Wow, I downloaded a binary from the website in that exact timeframe.

Luckily, it was only the CLI version, which I was putting on an Ubuntu
system...

------
thesimon
Are Transmission releases usually codesigned?

~~~
okket
Yes. And updates are checked within the Transmission app.

~~~
thesimon
Looks like it was signed by a different developer:

[https://news.ycombinator.com/item?id=12403906](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.

~~~
arm
Yep. That’s at least _one_ advantage for macOS apps that use _Installer.app_ ¹
to install; _Installer.app_ makes it really easy to see the certificate².

――――――

¹ —
[https://en.wikipedia.org/wiki/Installer_(OS_X)](https://en.wikipedia.org/wiki/Installer_\(OS_X\))

² —
[http://f.cl.ly/items/1s1E3n19273M1l3i3S2X/developer_id_insta...](http://f.cl.ly/items/1s1E3n19273M1l3i3S2X/developer_id_installer.png)

------
cjbramble
I will be using Deluge now.

------
zyxley
Time to switch to qBittorrent.

------
menzoic
According to the article, the title is wrong

"The infected file was available for download somewhere between a few hours
and less than a day."

~~~
tomasandrle
Thanks for the correction. I wrote the original title based on the warning on
their homepage: "Critical security notice to users who downloaded Transmission
2.92 for Mac on August 28th or 29th".

------
king_phil
I would have thought that Mac users would be a good target in general because
they might have better income than Windows users...

~~~
rahimnathwani
Maybe per person, but probably not in aggregate.

~~~
iopq
Android users have way more money in aggregate, but iPhone apps make more
money. This is because iPhone users have a lot more disposable income, while
Android users are cheap.

~~~
digi_owl
Or they re more willing to spend frivolously.

------
arianvanp
Again? :(

~~~
devn0ll
That's what I thought as well: [http://news.softpedia.com/news/transmission-
bittorrent-clien...](http://news.softpedia.com/news/transmission-bittorrent-
client-website-hacked-again-to-spread-mac-malware-507771.shtml)

------
mikegerwitz
I notice that they don't sign their releases.

