Along with the recent Linux Mint hijack, this really illustrates the need for people to verify programs they download. Though I think most people can't be bothered to verify the checksum on a file every time they download it.
On the other hand, the Windows and OS X App Stores are awful. Linux package managers are looking like one of the only straightforward ways to distribute applications securely.
Most people download software from websites using GUI browsers, while performing a checksum generally requires opening a terminal, changing directories to where the file was downloaded, and running the checksum program there. Maybe the web browser should provide a UI for doing checksums directly in the download manager. For example, each download entry could have a blank "checksum" text box where you can paste in the checksum given on the page.
Right. All I have to do is distribute the correct hash for my binary as a malicious software distributor because there's no authenticity verification at all, only that the bits in my binary blob match a certain pattern.
> In the case where the attacked has direct control over the website then you're right, it doesn't help at all.
I was pretty sure that's the threat model we were discussing: Software authenticity.
The only way to automatically know if a piece of software is legitimate is to have a trusted public key that can verify a signature.
Also, HTTPS is implied these days. If you're not using HTTPS, you are either malicious, negligent, incompetent, or working for someone who is some or all of the above.
> If you're not using HTTPS, you are either malicious, negligent, incompetent…
Or poor. Hosting large amounts of binaries over https isn't cheap. I just priced Amazon S3 and cloudfront and for the amount of data that I serve it would cost $300 per month. That's a lot to commit for a GPL-ed binary that brings in practically zero revenue. Maybe there's a cut rate VPS out there that can handle 150GB of data and 3TB of bandwidth per month on the cheap, but I haven't found it yet.
That would be a useful extension/plugin for browsers actually.
Maybe like pointed out in another reply, not for checksums but for signatures. So you just copy/paste the signature after selecting a file, and then it can verify it's validity.
Is there no such extension yet? it seems like there should be one already.
Maybe something like:
- have a database of common downloads and all their crypto info, which developers can update once they are validated
- have browser extensions that will check packages on download and alert if suspicious
You could pay for it with some sort of sponsorship from apps themselves, who have an interest in not getting compromised like this (it's terrible publicity).
No, Linux distributions offer packages and operating systems that are the result of painstaking work in which all upstream code is reviewed, patched for any inconsistency, and often blocked from going into public archives until known bugs are fixed.
Actually, most have scripts that pull the upstream source and build new binaries without any manual intervention. It is the responsibility of the package maintainer to review every change in code.
Generally, Linux package maintainers grab the upstream source, while most of these compromises seem to be of the binaries. And, of course, the maintainers generally review the changes before publishing them
> Along with the recent Linux Mint hijack, this really illustrates the need for people to verify programs they download. Though I think most people can't be bothered to verify the checksum on a file every time they download it.
Barring a situation where a CDN hosting the download is compromised but the main site is not hosted on the CDN, it's extremely unlikely that someone would have the ability to inject malware into the download and not have the ability to make the checksum match. Posting checksums is actually pretty useless, and was something that used to be used to deal with the possibility of malicious mirrors, but doesn't provide any security against mitm attacks (unless the main site is secure but the downloads aren't which is idiotic by 2016 standards anyway), the site getting hacked, etc.
Digital signatures are a little bit better if the key is kept safe, since hacking the site and replacing the binary won't allow a random person to produce a valid signature, although ability to modify the source code would still allow someone to introduce backdoors into the next version, but there's still a huge problem where you need some way to determine what key was supposed to be used to sign the binary in the first place, so just posting a signature on a website is also basically useless.
Digital signatures can work if there's some sort of centralized distribution method, or for safely updating software that's already installed.
>unless the main site is secure but the downloads aren't which is idiotic by 2016 standards anyway
https adds a performance hit. The security of "checksum over https and actual file over http", if the checksum is checked, is the same as "actual file over https", barring preimage attacks.
>Practically it is difficult to provide SSL protected downloads at all. Many important software projects can only be downloaded in the clear, such as Ubuntu, Debian, Tails, Qubes OS, etc. This is because someone has to pay the bill and SSL (encryption) makes it more expensive. At the moment we don't have any mirror supporting SSL. We're looking for SSL supported mirrors to share the load.
Is it not true that mirrors supporting SSL are more expensive?
No, it's not true anymore. From the link you replied to:
"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that."
- Adam Langley, Google
Getting an SSL certificate used to be a cost, but that's taken care of now by https://letsencrypt.org/.
So can you recommend a mirror for them that supports SSL?
There are multiple named projects there that aren't using SSL, and I don't think it's just laziness. If you know of a way for them to use SSL mirrors for no additional cost, I'll work on getting them to switch over.
This is only true for Intel and AMD x86_64 servers that have hardware accelerated AES with the AES-NI instruction set. Software implementations of AES and the other ciphers are much, much slower than AES with hardware acceleration. RC4 was the fastest decent software cipher for a while, but that has been found to be insecure and its use is discouraged. The fastest possible replacement would probably be ChaCha20, but that cipher is not widely supported yet. The other software ciphers are very slow, and certainly wouldn't be considered as "fast yet".
Granted, the project I saw this reasoning on (https://www.whonix.org/wiki/Download_Security) is one where users are especially likely to do security checks, and they generally aren't satisfied with the security of SSL anyway.
> just to save a negligibly small number of CPU cycles
The link above says they can't afford the additional cost. If it's so negligible, would you sponder the cost of those extra cycles? I'm sure they would host on SSL if someone covered the cost.
Quote from a google engineer in 2010 (it's only gotten cheaper in the last 6 years w/ advances in CPU tech) regarding SSL overhead:
> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. [0]
None of affects the point they're making, which is that they can't find SSL mirrors that aren't more expensive. If you find one, let them know and I'm sure they'll be happy to switch over.
It is 2016. SSL is not slow anymore. Only case it could be deemed slow would be on a webpage where the browser has to download a ton of small files likes images. Each image would require a new connection and each connection would require full SSL handshake. Even then the fix is not to not use SSL but to bundle all the images/files into 1.
Keep in mind the topic at hand is downloading a single large file, the TLS handshake is a rounding error of the total time, regardless of where you are in the world.
I thought only apps signed by "identified developers" are run by default on Macs with Gatekeeper now. Shouldn't code-signing have prevented this? Unless they inserted the malware before the signing process.
>I thought only apps signed by "identified developers" are run by default on Macs with Gatekeeper now. Shouldn't code-signing have prevented this?
"By default". Most developers don't bother to register, and lots of people change the default (and after that, they can right click to open the app and bypass the warning).
Anyone can sign up for the Apple Developer Program to become an "identified developer", so there's nothing that stops an attacker from signing their malware.
And according to the analysis [0], this is exactly what they did. They used a different cert to sign their malware.
I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.
Yeah, I think this is a major issue on OS X. For the average user it is impossible to tell who signed an app, if it is sandboxed, and what permissions it has. Hell, using the codesign command to extract entitlements from all binaries in a package is hard even for advanced users...
(There is third party tool named RB App Checker which does make these tasks a bit easier, though)
“The two KeRanger infected Transmission installers were signed with a legitimate certificate issued by Apple. The developer ID in this certificate is “POLISAN BOYA SANAYI VE TICARET ANONIM SIRKETI (Z7276PX673)”, which was different from the developer ID used to sign previous versions of the Transmission installer. In the code signing information, we found that these installers were generated and signed on the morning of March 4.”
For the end user? No, it wouldn’t. As thesimon and jakobegger, respectively, said:
“And according to the analysis, this is exactly what they did. They used a different cert to sign their malware.
I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.”
“Yeah, I think this is a major issue on OS X. For the average user it is impossible to tell who signed an app, if it is sandboxed, and what permissions it has. Hell, using the codesign command to extract entitlements from all binaries in a package is hard even for advanced users...
(There is third party tool named RB App Checker which does make these tasks a bit easier, though)”
What. That's interesting -- Polisan is a relatively well-known paint company in Turkey. I don't think they have a part in this -- maybe they did not store their private keys well enough?
In Debian and Ubuntu at least, all published files containing binary executable files (ISOs, .deb packages, etc.) are hashed and the hash signed by a well-known system pre-installed PGP key.
Given trust in the protection of the private key used to sign the hash list file the integrity of the executable content can be proved (assuming useful SHA1 collision creation is prohibitively expensive).
Coincidentally I was writing a Bash script this weekend to auto-install (Ubuntu) releases into LVM volumes and it includes the following code to verify the download:
set -e
# ...
ISO="${NEW_DIST}-desktop-${ARCH}.iso"
for F in SHA1SUMS SHA1SUMS.gpg ${ISO}; do
if [ ! -r $F ]; then
wget http://cdimage.ubuntu.com/${FLAVOUR}/daily-live/current/$F
fi
done
if ! gpg --verify --keyring /etc/apt/trusted.gpg SHA1SUMS.gpg SHA1SUMS; then
echo "Error: failed to verify the hash file list signature; files may have been tampered with"
exit 2
fi
if ! grep ${ISO} SHA1SUMS | sha1sum -c; then
echo "${ISO} is corrupted; please try again"
exit 1
fi
> (unless the main site is secure but the downloads aren't
> which is idiotic by 2016 standards anyway), the site
> getting hacked, etc.
It's not idiotic at all. You let anyone who wants to spread the load by providing downloads, but you use checksums - behind https - to ensure they can be trusted.
You'd think there would be some sort of global torrent network that simultaneously distributes binaries and signatures.
Doesn't seem like a horrible idea to me: you could just add the developer's key to your client, have your client broadcast interest, receive a _signed_ list of available software with appropriate magnet info... Download servers could serve as initial trackers until enough information has propagated through the network for downloads to be trackerless.
Checksums? Guaranteed. Signatures? Acquired. Checking? Performed automagically.
Granted, this just moves the point of failure to the developer's key. (Key acquisition needn't necessarily take place on the developer's site, a friend in the network could pass you a link containing the dev's key and the application's magnet info.)
There is also the web of trust for PGP, which sort of solves the problem of needing a central store of the key. It does require being inside the web though (bootstrapping). But once you are, you can construct how much you trust a key from someone you haven't met.
>Though I think most people can't be bothered to verify the checksum on a file every time they download it.
This wouldn't help anyway. If the malicious party had access to alter the downloads (as they did here) they could just as well change the checksum shown on the page to.
>On the other hand, the Windows and OS X App Stores are awful.
Haven't used the Windows one, but what's "awful" about the OS X one? Quick, one click, installations, isolated, signed, easy updates.
Might be bad for the application developers somehow, but I don't see anything much bad about it from a user perspective -- except maybe the lack of trials. Then again I've been able to get a refund any time I bought an app that was subpar and written to Apple (that was 2 times).
In the original thread, the initial reporters specifically pointed out that the files they had downloaded did not match the checksums on the Transmission page. My guess would be that the attackers compromised a mirror, but not the web server serving up the user-visible page with the checksum.
Linux package managers are looking like one of the only straightforward ways to distribute applications securely.
Unless you are a small independent app developer. Virtually no distribution wants to take proprietary software. And you have to package for a wide variety of different distributions.
On the other hand, the Windows and OS X App Stores are awful.
The Mac App store works pretty much effortless for me. It's sometimes a bit slow, but other than that it's pretty trivial to use.
It's not at the time of installation, but prior to updates the package management system will check signatures of the packages. (And it will only accept packages signed with your key, so the attack used against Transmission wouldn't work)
The question is whether we should trust proprietary software even if it is downloaded securely. I consider "hard to get proprietary software into the official repos" as a feature. Unfortunately it's not as hard as you make it sound in most distributions.
There's no completely secure way, except for getting the public key directly from the developer over a trusted channel (or in person). And even that won't protect you in case the developer's keys gets compromised.
But there are a number of things that can be done:
- always verify the checksum (if available), in case the download mirror (but not the web site itself) got compromised.
- check for strange strings in the binary (use "strings" and "grep"). E.g. URLs
- scan the downloaded file on Jotti or VirusTotal.
- unpack the binary manually with 7-zip or similar if it's a self-extracting file.
- check installation scripts, build files, etc. (if applicable).
- if downloading source code, check a couple of files at random. Will most likely not protect you, but if everyone does it, it helps detecting embedded malware (or bugs) early.
- run "strace" (Linux/Unix) or "FileMon" (Windows) or similar software and log what the software does when you install and run it for the first time.
The app made it onto the OSX App Store and the author's certs were revoked. This isn't a case of verify source, verify application. This is a case of anything can be infected and it's damn near impossible to check everything.
Transmission wasn't on the Mac App Store, though the app was signed. Apple offers developers the ability to sign their apps distributed outside the Mac App Store to certify them as an Apple-identified developer https://developer.apple.com/library/ios/documentation/IDEs/C...
As such, checking the source is still very much relevant here since this wasn't a compromised app in the Mac App Store, it's an app distributed outside it.
- The APIs exposed to Mac App Store apps are more limited (because the OS X sandbox is not completely comprehensive in what it provides). This limits the types of apps that can be sold on the store.
- There's no means of providing paid upgrades. E.g. for a major version bump, which a lot of developers rely on to keep their business afloat.
- The store interface and navigation are also much slower than the iOS counterpart.
- Recently some certificate issues rendered users unable to open their apps.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
- There's no means of providing paid upgrades. E.g. for a major version bump, which a lot of developers rely on to keep their business afloat.
Apple and other do this by simply numbering the names of apps. They don't allow you to specify special "upgrade" pricing, but the effect of this was that developers no longer really have full retail pricing and everything is just set to the upgrade price.
Logic Pro 8 for instance used to retail at $499. The upgrade price was $199. Now Logic Pro X on the Mac App Store is just $199 regardless of whether you are first time user or someone who had the previous version.
- The store interface and navigation are also much slower than the iOS counterpart.
I haven't really found that the Mac Store is any slower. I've found that they are both slow.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
I don't believe it will even show you newer versions of the apps as long as the developer properly specifies the minimum OS version.
Isn't it quite popular on Debian and derivates too? It's Pre-installed with GNOME there as far as I know.
Fair enough, it's extremly interesteing. Never saw such an infection in the "free World", outside the laboratory.
I hope they can find the source.
At least Linux distributions usually compile from source. I wonder if the source was also modified, or only the binaries.
EDIT: I downloaded the Transmission 0.90 and 0.91 source code and took a look. The diff between them is quite small, with nothing suspicious being removed, and the 0.90 .tar.xz MD5 matches what Fedora used (according to http://pkgs.fedoraproject.org/cgit/rpms/transmission.git/com...). So, unless there was also a malicious source code change the developer didn't catch, Fedora's package should be clean.
Do the developers have an explanation anywhere as to how this happened? The homepage ( https://transmissionbt.com/ ) has a big red warning to upgrade to 2.91, but I can't find any info about how someone went about putting malware in the download.
Yep, this deserves a more detailed explanation (or maybe they still don't know what happened). I updated from the previous version to 2.90 through the app built-in update, and I don't seem to have any "kernel_service" process running. Can someone that has that process in their system tell us where they downloaded the program?
I also did not have that process running in the background. I just updated through the app to 2.91 and it's still not there. So, I am also curious where they got Transmission from.
Back when Apple still made Mac OS X Server as a separate operating system, they included ClamAV¹ to scan for malware in mail. They don’t include it anymore, but ClamXav² (been around since 2004³) is a nice GUI for ClamAV that I’ve been using for a while now.
I run a private mail server and swear by ClamAV to help reduce noise and pollution that accumulates and spreads through my server, but I don't think I've ever had any luck with it being a good front line defense against up-and-coming malware, whether it targets Windows or Mac. I don't think I would recommend it as a primary malware scanner for a Mac, or Windows.
If you release commercial or popular open-source software, it's probably a super-bad idea to keep your signing key on a notebook computer you use outside of the office.
Have a trusted machine kept in a secure location to sign it for you if that's practical.
>Allow downloading files from http servers (not https) on OS X 10.11+
Mac version affected in OP was 10.10, though.
Maybe it had something to do with
>Change Sparkle Update URL to use HTTPS instead of HTTP (addresses Sparkle vulnerability)
?
Edit: it appears the infection was downloaded from a website, in which case this doesn't help. But one did say the in-app update failed on incorrect signature first.
>Allow downloading files from http servers (not https) on OS X 10.11+
This reads like they disabled Apple's "App Transport Security", which only allows HTTPS connections unless a program explicitly makes an exception. Introduced in iOS 9 and OS 10.11 (El Capitan). I bet the failing HTTP connections caused a bug in Transmission, and it was an easier fix to disable ATS than to transition whatever connection to HTTPS.
> and it was an easier fix to disable ATS than to transition whatever connection to HTTPS.
Pretty sure this is for arbitrary downloads. Unless you want to prevent transmission to download from http based sources out of principle it makes no sense to do anything other than opting out of this behavior.
Right, being a web connected app based on a distributed community of other clients, it's very possible that the encryption isn't possible to implement on their end. IIRC it's only blocking HTTP connections, so the torrent transfers themselves aren't affected (unless it's masking that as HTTP traffic to avoid easy inspection?), but there may be other things that require HTTP. Connections to trackers maybe?
On the other hand, El Capitan came out last September. If this just changed in 2.9.0, the restricted HTTP connections can't have been that big of a problem.
It's probably for "web seeds" or similar, where a torrent file's author specifies alternate URIs where the content can also be found. Transmission has no control over whether the torrent file's author specifies http or https, it has to allow both (and http is actually safe, since the downloaded file goes through the same piecewise checksum as if it were downloaded from a peer).
Additionally, what does the malware do? "OSX.KeRanger.A" appears to be a name that Apple assigned it in their malware definitions, but Google doesn't know anything except the pages about Transmission.
I'm curious what sort of malware we're looking at. Botnet? General remote access/control? Harvesting keychains?
Of course, and if you only have the one backup drive, be wary of connecting it to an infected computer with read/write access. Link posted in another comment suggests that this malware has encryption of Time Machine backups in development (should be safe this time around?).
Safer option would be to create a write-only network share on another computer and copy files to that.
that feels like a pretty week standard for knowing if your machine is infected. I will look for a virus scanner myself, and seriously think about reinstalling if it finds anything
Yeah I know, it is the lowest effort. But I'm not running it on my main system. Worst case I'll have to reinstall (unless it messes with the hardware, firmware changes for example).
The strength of a chain is the strength of its weakest link, and the more "apps" are provided as the system the longer and more vulnerable is the chain.
When it comes to checksums with have the chicken egg problem plus the collision attack of md5.
MD5 has been the standard for too long (and is deprecated since 10 years for crypto checksum). And for next generation of softwares to install that don't do modern checksum how can they trust the download of the package required to check for whatever the new format?
Plus the new format is less likely to be checked without errors. A off by one character could easily be discarded in checking given the number of packages that are now required to be installed and the human limitation in focus.
Human are the limiting factors, and security is modeling the user in a kind of grotesque caricature of a robot that can check thousands of informations perfectly and remember 20 characters passwords for tens of appliances.
There is a tyranny of computer engineers regarding what is safe for people having a life not concerned about geeky technology that is a tad annoying.
People have the right to be human and to fail is human. The burden put on human to make the system safe in order to avoid costly for the bosses human interactions is way to high.
And since computer security always blame failure on human behaviour I begin to positively dislike it.
> There is a tyranny of computer engineers regarding what is safe for people having a life not concerned about geeky technology that is a tad annoying.
You know you can make that complaint about any tool or technology, right?
"Gosh why do I have to follow all these rules and observe traffic lights to drive a car?" (something that actually intimidates me, in fact, because I've never driven a car.)
"Why do I have to worry about cutting or burning myself or someone else while trying to cook a meal?"
"Why are all these procedures and protocols, like schools and banks and taxes, required to function at all in contemporary society?"
Until computers advance to the point of being artificially intelligent familiars that can figure out exactly what we want from a simple vocal command and do something even better, we're gonna have to put in a little effort from our end to make them work the way we want them to.
> You know all engineers do not always blame users?
> There are fields of engineering where an accident even due to human causes is systematically seen as an engineering problem.
In those other fields, such as automobiles, an accident by a person may cause death of another.
On a computers your careless may not cause someone else to outright die (which tends to cause a lax attitude on the part of users) but they can still cause someone else harm, like inadvertently leaking someone's financial information or causing malware on your device to participate in a DDOS attack on someone. Time and again it's been proven that users are often the weakest link in this field no matter how tight the security is. It's only understandable for the engineers to be annoyed.
I've become increasingly paranoid lately, given that things like these happen and major bugs are uncovered in software that I use almost every day.
It's good that the Transmission developer reacted quickly and made waves so that people can at least be aware that they might have been exposed..
But I wonder how many more applications from the hundreds that I have installed on my machines contain weird stuff - either intentional (for money) or unintentionally (result of a hack).
Open source software is especially vulnerable to this kind of stuff.
If a hacker gets access to a server holding the binaries for an open source app (which most people download), the hacker can just compile the program from sources and add his own code in there and place the installer online.
Given that many big governments are now involved in the information wars, this scenario is quite likely.
> "Open source software is especially vulnerable to this kind of stuff."
I am sorry, what? Why would open source contain more bugs/hacks than closed source specifically? It is more often in the news for few reasons, including that many projects are widely used. However it's against any PR from companies to have their security issues disclosed like they are in open source so they try to minimize the exposure. See [1]
I don't follow, what does it matter for the "distribution model" if the software is open- or closed-source? The problem with SourceForge were its malware-riddled installers, how would it be any better if the downloads were proprietary software?
The risk is not in the software itself, but in the server which hosts the installers. A hacker could just build the software from sources (adding his backdoor) and replace the original installers with his own, if the server is not properly secured.
The risk is exactly the same with proprietary software. A hacker can unpack the installer and create a new one with his changes. Or, as they often do, create a wrapper which installs their malware and then calls into the original unmodified installer.
If a hacker gets access to a server holding the binaries for an open source app (which most people download), the hacker can just compile the program from sources and add his own code in there and place the installer online.
Code signing is used to prevent this. So, either the attacker has an Apple developer account (and is hopefully traceable through their credit card information), the Transmission project was sloppy with their signing key, or the machine of the developer with the signing key was compromised.
People have been ranting negatively about the Mac App store. But this is exactly why we need sandboxed applications by default (which is what the Mac App Store enforces). A sandboxed application cannot take your data hostage.
(Yes, I understand that App Store distribution is probably not possible for a Bittorrent Client.)
So, either the attacker has an Apple developer account (and is hopefully traceable through their credit card information), the Transmission project was sloppy with their signing key, or the machine of the developer with the signing key was compromised.
Sorry, I forgot another possibility: some other developer's key was compromised.
Or, as is the case here, the malicious party was simply issued a key by Apple (for apps that are downloaded from places other than the Mac App Store, developers can get a unique Developer ID from Apple (for free) and use it to digitally sign their apps, the purpose being that Apple can revoke it after the fact if it turns out to be malware):
“The two KeRanger infected Transmission installers were signed with a legitimate certificate issued by Apple. The developer ID in this certificate is “POLISAN BOYA SANAYI VE TICARET ANONIM SIRKETI (Z7276PX673)”, which was different from the developer ID used to sign previous versions of the Transmission installer. In the code signing information, we found that these installers were generated and signed on the morning of March 4.”
OK so let's imagine sandboxing is on by default, then "Transmission" pushes an update that asks for read/write access to the whole home directory. You don't know if Transmission has some legitimate need for that or not, so you just shrug and click Allow. Boom—infected.
So I think sandboxing is basically useless against these kinds of attacks. Either they allow apps to elevate their entitlements in an update, or they don't and developers will always out-out from the start (or pick the widest set of entitlements available).
If sandboxing is forced with no opt-out, then users will have to jailbreak their computers so they can install Parallels...
If you are talking about the 'open directory' dialog. Well, if a user is careless enough to just give a sandboxed app access to their complete home directory - tough luck.
So I think sandboxing is basically useless against these kinds of attacks.
No, it's not, because no entitlement allows blanket access to the user's home directory. Hence, an application cannot just encrypt all of the user's data.
"Open source software is especially vulnerable to this kind of stuff."
I'm not sure I follow on this front. Proprietary software could be compromised (whether intentionally by the vendor or unintentionally by some outsider working on the software) effectively forever with no one noticing. At least with OSS, the number of eyes on the source makes it less likely that an exploit will exist for long (though the definition of "long" could vary wildly dependent on popularity and the skill level of the software's normal users).
"Given that many big governments are now involved in the information wars, this scenario is quite likely."
Again, this one seems to point more to proprietary software then OSS. A government only needs to compromise a single company to make an exploit happen in commercial software. OSS exploits can be caught by the Linux distribution vendors that package the software, the users, the developers themselves (who are often working at different companies and in different nations), etc.
So, it may seem easier to compromise an OSS project, by attacking the distribution server and uploading a compromised binary built from source with patches...but, there are many good ways to guard against that (though any single mitigation, like signing with developer keys, can be compromised, the more eyes the less likely it is to succeed for long). But, if a government compromises a company, or someone within that company, all bets are off, and the problem literally may never be found.
I was thinking more about the users on Macs and Windows who use open source software..
The risk is not in the sources, but in the server which hosts the installers.
A hacker could just build the software from sources (adding his backdoor) and replace the original installers with his own.
> but why bother when you can compile the app from sources?
Well, imagine that you are the attacker here. Would you rather keep your malware source in sync with the upstream code and build every target every update, or just use an off the shelf binary wrapper. Would you answer the same if you were targeting more than one app (in the case of a CDN attack)?
The only scenario in which source level malware makes sense to me is this: you are targeting a specific application and you are able to get your code into the project's SCM. In this scenario OSS is no more vulnerable than closed source.
> Open source software is especially vulnerable to this kind
> of stuff.
Give it 2 or 3 years and stories will come trickling out about how most OS apps have had commits from hackers, governments etc. So far most source checking - to the extent that it happens at all - is all about buffer overruns and the like; micro stuff that's easily catchable. Well, you say that, but, you know, heartbleed etc. But what about whole modules designed with two purposes in mind?
Open Source software has existed for more than 2 or 3 years, you know.
All software is vulnerable to bad actors writing malicious code. What makes it any safer if its proprietary software? In any case, in a pessimistic scenario you'd have to change your sentence to "give it 2 or 3 years and stories will come trickling about how ALL apps, open or closed source, were tampered with by hackers, the government, etc".
> > Open source software is especially vulnerable to this kind > of stuff.
> Give it 2 or 3 years and stories will come trickling out about how most OS apps have had commits from hackers, governments etc. So far most source checking - to the extent that it happens at all - is all about buffer overruns and the like; micro stuff that's easily catchable. Well, you say that, but, you know, heartbleed etc. But what about whole modules designed with two purposes in mind?
Free Software has existed for over 20 years. Not to mention the fact that the same problem you describe is far more trivial for proprietary software. There's no straightforward way to find out if it's backdoored (although, luckily quite a few backdoors are done badly so we can find out). The point is that if you assume that all free software is compromised, you have to assume all proprietary software is compromised. I'd prefer to have some free software be compromised because then I'm not at the mercy of the vendor to fix it.
Edited to add: If anyone has a copy of the DMG, sha1 5f8ae46ae82e346000f366c3eabdafbec76e99e9, please link me a copy via email (brendandg@nyu.edu) or twitter DM (@moyix).
Maybe take a look around https://build.transmissionbt.com/ - but then again maybe the svn repo wasn't compromised? I tried a "svn diff svn://svn.transmissionbt.com/Transmission/tags/2.90 svn://svn.transmissionbt.com/Transmission/tags/2.91" and didn't see anything suspicious on a fast scroll-through
Side topic: probably not a good idea to expose Jenkins externally, especially if you don't keep Jenkins up-to-date all the time (for transmission bt it is up-to-date right now). This Jenkins probably contain the key to the svn server, so if someone finds a hole...
I do not think it was the build server, though. According to this analysis[1], the developer used a different key to sign the build (all Mac apps need to be signed or the default behavior is to reject that App. You can permanently disable this behavior in settings, or just for on app by holding control while opening the App, which a lot users who use transmission probably do because not all legitimate Apps are signed). Anyways, since the app was signed by a third party's certificate (which was approved by Apple), chances are only the website was compromised. If the build server had been compromised, the attack would have had access to the developer's certificate and they would most likely have used that.
Users who have directly downloaded Transmission installer from official website after 11:00am PST, March 4, 2016 and before 7:00pm PST, March 5, 2016, may be been infected by KeRanger. If the Transmission installer was downloaded earlier or downloaded from any third party websites, we also suggest users perform the following security checks. Users of older versions of Transmission do not appear to be affected as of now.
We suggest users take the following steps to identify and remove KeRanger holds their files for ransom:
1. Using either Terminal or Finder, check whether /Applications/Transmission.app/Contents/Resources/ General.rtf or /Volumes/Transmission/Transmission.app/Contents/Resources/ General.rtf exist. If any of these exist, the Transmission application is infected and we suggest deleting this version of Transmission.
2. Using “Activity Monitor” preinstalled in OS X, check whether any process named “kernel_service” is running. If so, double check the process, choose the “Open Files and Ports” and check whether there is a file name like “/Users/<username>/Library/kernel_service” (Figure 12). If so, the process is KeRanger’s main process. We suggest terminating it with “Quit -> Force Quit”.
3. After these steps, we also recommend users check whether the files “.kernel_pid”, “.kernel_time”, “.kernel_complete” or “kernel_service” existing in ~/Library directory. If so, you should delete them.
"It will then sleep for three days. Note that, in a different sample of KeRanger we discovered, the malware also sleeps for three days, but also makes requests to the C2 server every five minutes."
Isn't it possible to fire a takedown notice to that server? I mean KeRanger committed a felony and Amazon (assuming you mean Amazon's EC2 server) might react quickly if they realize what has happened. It might save a lot of computers from getting destroyed. As long as the server is somewhere in the Western world, it should not be a problem.
The server isn't on EC2, it's hosted on Tor. The malware uses an HTTP-to-TOR gateway service (onion.nu and onion.link) to pull down the encryption key and README file from one of three different hidden services. In theory you could try to get the gateways to block the connections, but I'm not sure they're likely to be cooperative.
I went to a Mac developer's group a few years ago in Toronto. One of the devs was working on Mac antivirus software but basically had the attitude that it was unnecessary, and spent most of the meetup trashing Windows. Just really bizarre and inept behaviour. Not sure I trust his anti-virus software. Too bad I can't remember which one he was working on.
Can anyone tell me if this also applies to brew's cask's builds? I needed to download CentOS the other day and wanted to go with a torrent. I got pretty pissed after I realized that BitTorrent installed some adware called Spigot. I tried to remove it as good as possible (I mainly killed the process, removed `Library/Application Support/Spigot` and ran a `sudo find / | grep -i Spigot`).
Ironically I decided to use the good, ol', trusted open source alternative transmission because I just read on HN that Transmission gets updated again...
Looks like it. The homebrew cask download url is using http instead of https, which was one of the problems stated in the forum discussion. There's currently an open PR to fix it https://github.com/caskroom/homebrew-cask/pull/19506/files.
For anybody stumbling upon this, installation via homebrew-cask was _always_ safe[1] thanks to checksum verification. The caskfile has been updated to https[2] and version 2.92[3].
All that stuff - bittorrent, soulseek, calibre etc - lives in a vm, with access to the host only via samba shares. I'll decide what you see and where you can write. Yes, it's great you download stuff. No, you can't write to the stuff I'm sharing. Yes, having a web-server serving up books to the outside world is great. No, you can't serve up anything from my filesystem to anyone who feels like it.
When you can't (be bothered to) vet the source code, stick it in a vm. On a sensible machine with an ssd it's only 10 seconds away. Why risk it. Especially if the software you want/need to run only works under windows.
Sure, in theory. Are there any current exploits for VirtualBox?
The way I see it, they're more secure that running the same apps on bare metal. Ubuntu host running a Fedora VM; the latter (with Transmission etc) only running when I need the apps running - seems an almost entirely painless way of providing a lot of security.
Yes! Some reliable ways to extract an RSA key, and some less reliable ways to swap two cache lines. Virtualization on x86 is a helpful tool for configuration management, but should not be mistaken for a security feature.
This makes no sense. VMs are by far the most secure form of isolation. No one is going to get infected with malware that escapes VMs - it is far too valuable.
Yes but if you run a compromised App in VM A and have your sensitive data in VM B then they have to break out of the VM A and then break into VM B. It's no longer worth the effort. There are often easier ways like phising.
Or the Mac App Store itself. Its enforced sandboxing would have provided a decent first line of defense against this, but torrent clients can't be submitted to the App Store due to Apple not liking the legal aspects, not to mention the other issues people have with it. (Outside the store, apps can still opt into sandboxing, but that wouldn't help with a malicious installer.)
It should be able to sandbox Windows Apps, except for Metro/Modern UI Apps and Microsoft Edge.
Too many programs are having a backdoor or Trojan in them now. It is a good idea to run any app that accesses the Internet in a sandbox first to see what it does.
Yes. Back when I still used Windows five years ago, the app was an essential tool for me. All web browsers, downloaders and basically anything else that I consider high risk must be run in a sandbox, which is routinely emptied. Less risky apps are sometimes also installed in a sandbox, which is emptied much less frequently. And it's great for trying out trial versions of software before I fully trust their publishers. I didn't run any antivirus on that machine at all and I'm that confident. Nowadays I've switched to OS X but I still miss the easy sandboxing of basically any app.
Just a warning: by default it doesn't protect your documents from reading.
It isolates the process, all writes (filesystem, registry) go to the sandbox instead of the host filesystem, so a malicious software can't easily install itself. But reading data is mostly unprotected by default, so a malware ran in a sandbox may steal some sensitive data. To protect such data you have to pre-configure sandbox manually.
It's a very old P2P file sharing network modeled after Napster. It's main propositions (in my opinion) are its active users who share harder-to-find electronic music, and its discussion groups which are available inside the app.
I didn't know Soulseek is still alive - brings me back to the days of Direct Connect / DC++ and hunting down rare live sets and (as you mentioned) electronic music over ISDN/dial up.
You can also lease a VPS (anonymously even) and use Deluge with a webGUI. Said webGUI can be a Tor onion service, for better isolation.
But still, this is about malware in Transmission itself, not anything downloaded using it. So the fact that it's a BitTorrent client is rather beside the point, I think.
This article[1] says Transmission is doing to offer a way to check, but I'm not sure it's on the site yet. Apparently tomorrow is the ransomware activation date for people who installed the infected version on Friday.
I updated in app and don't seem to be, an official confirmation of how this happened and why in-app updates were seemingly not affected would go a long way.
The headline should probably say "at least Mac". I hope we soon learn the source of the compromise, but nothing so far indicates that Linux distributions' packages would be affected by a Mac malware.
The headline should definitely say "at least Mac". It so annoying to hear about "computer viruses"... (protip: it's Windows, Osx, well, maybe even Linux virus).
Looking more at this issue, it seems like the problem may have been (hard to tell, not a lot of information) a compromise of a third-party mirror to which https://www.transmissionbt.com/ redirected users; the checksum on the HTTPS site was unaltered, and was used to identify the altered download.
Perhaps a defense against this kind of attack would be an altered version of HSTS - one that protected the content of download links, and not just of sub-resources included on the page.
It might be worth updating the title to specify the vulnerable version (2.90) and the platform (OS X - from what I can tell, this is not a vulnerability on Linux or Windows).
I can't think of a more hostile opponent than an HIV virus. And we're still not sure if Transmission was spreading the virii intentionally, making the condom analogy even more fitting.
But humans and viruses aren't competing in the same game. A better metaphor for the adversary in that situation is the person you're having sex with poking a hole in your condom.
If you're worried about contracting STD's, don't have sex with a dirty prostitute, not even if you're wearing a condom, nor if you're sitting inside of a car.
Running software in VMs to stay safe is not a new idea. So is it effective in this case?
Just because attackers can break out of VMs, doesn't mean that they always do. I wager most malware out there isn't set up to do that.
Locking your car door won't keep a dedicated attacker out of your car. Simple ceramic shards from a sparkplug will get them through the window with barely any effort at all. Nevertheless, locking your car doors is an effective way to reduce your risk, as it dissuades more opportunistic attackers.
As far as I know, malware generally won't run in VMs. Because its enemies use VMs to study it. The side benefit is that VM breakout is rare. Except from the NSA ;)
Maybe closer to "everyone knows safes can be cracked". Compared to lockpicking, or the other, more brute force ways to get past doors, the skill needed to find and exploit a new (0day) vulnerability is relatively specialized, albeit abundant enough for worry.
> from Greek analogia "proportion," from ana- "upon, according to" (see ana-) + logos "ratio," also "word, speech, reckoning" (see logos). A mathematical term used in a wider sense by Plato.
so, what do you think where logic comes from? I'll spare you the effort:
> [...] from properly feminine of λογικός (logikós, “of or pertaining to speech or reason or reasoning, rational, reasonable”), from λόγος (lógos, “speech, reason”).
There is no analogy without logic. I even fail to recognize a difference between speech and logic, speech without logic, by analogy, would be just noise.
Your extremely ignorant argument immediately implies that the clubs used to hit baseballs are necessarily related to flying mammals.
The facts that the english word analogy descends in a complicated manner from a greek word referring to mathematical proprotions, and the english word logic descends in a somewhat less complicated manner from a greek word referring to speech, and that those greek words shared their pronunciation, tell us nothing about the relationship between analogies and logic.
A standard chinese term for "analogy" (also, "metaphor") is 比喻 biyu. The term for "logic" is 逻辑 luoji (it is a loan word from english). Are you prepared to grant that, while analogies and logic are necessarily intertwined for people who speak english or greek, they are unrelated for people who speak modern mandarin chinese?
The similarity between according to" + "ratio," and “of or pertaining to speech or reason or reasoning, rational, reasonable” is just too simple and striking to be missed and forgotten.
No linguistic reasoning is needed however, to see that an analogy essentially needs logic to work in any language. It helps however. EG in English tongue still language in an idiomatic metaphorical sense, analog to the original meaning of logos, tongue, metaphorically referring to speech.
My argument is not ignorant, anyway, it's arrogant.
I don't know about the second part of your argument, where you claim you don't need any linguistic reasoning to see that analogy needs logic (I'm personally not convinced). However, your argument about the connection-in the context you are putting it in-of the words logic and analogy is absolutely false.
Αναλογία means the comparative association of two (antithetical) objects in quantity, size, etc.
I'm sorry, the initial analogy, that a condom is easy to pierce was just an example for the general assumption, that security is easy if the thread is not purposefully malignant, for varying measures of malignant.
Someone who doesn't even understand that and that the linguistic argument is of the table, and still keeps going, shouldn't try to talk about logic, as right as some of the individual arguments might be. Ana-logically, I shouldn't be writing any more about this.
> There is no analogy without logic. I even fail to recognize a difference between speech and logic, speech without logic, by analogy, would be just noise.
Sure. That's why sometimes we see such bad analogies, the logic doesn't match so well the actual idea. When the idea you are trying to convey isn't that complicated at all you're probably better off using just pure logic and not complicated constructs such as analogies.
As for speech, indeed, there's a deep logic bounding the language structures we use. The problem with language (logic and meaning wise) is that language is relative to the environment and to the speakers of the conversation. You have to figure out the "language game" where the conversation is being held. As for logic, we expect no subjectivity (if there is subjectivity it's bad logic).
Threw away Transmission as soon as I read this (even though I was running a old version), my trust is pretty much gone now, never installing it again.
Shame because it really was a nice app.
I don't even trust websites and emails, so not sure why you would trust a bittorrent client. I still use these tools, but with some some caution. Your level of caution is up to you. Other posters suggested things such as verifying checksum and virtual machines.
Not an official comment, but from other parts of the hacker news thread it sounds like one of the mirrors the main site redirects to was hacked, not the main site itself. The SHA sums on the main site where apparently unaltered. So it sounds like the only fault on the developers is trusting that mirror.
I don't understand this attitude, the Transmission team responded immediately to the problem. There's no indication that this was the result of some problem specific to the application or its developers.
Transmission was and remains my favorite torrent client on OS X, although I still like the torrent information presentation uTorrent had, and I still will run my old pre-adware 1.6.4 if I want more detail on a swarm.
Given that older versions still work, it seems exceptionally silly to delete an old version because of a site compromise.
Same here, into the garbage it goes. What did you switch to by the way, Deluge? I switched TO Transmission because it was open source and supposed to be pure.
354 comments
[ 3.2 ms ] story [ 291 ms ] threadOn the other hand, the Windows and OS X App Stores are awful. Linux package managers are looking like one of the only straightforward ways to distribute applications securely.
A checksum is NOT a substitute for a digital signature.
https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...
In the case where the attacked has direct control over the website then you're right, it doesn't help at all.
I was pretty sure that's the threat model we were discussing: Software authenticity.
The only way to automatically know if a piece of software is legitimate is to have a trusted public key that can verify a signature.
Also, HTTPS is implied these days. If you're not using HTTPS, you are either malicious, negligent, incompetent, or working for someone who is some or all of the above.
Or poor. Hosting large amounts of binaries over https isn't cheap. I just priced Amazon S3 and cloudfront and for the amount of data that I serve it would cost $300 per month. That's a lot to commit for a GPL-ed binary that brings in practically zero revenue. Maybe there's a cut rate VPS out there that can handle 150GB of data and 3TB of bandwidth per month on the cheap, but I haven't found it yet.
Maybe like pointed out in another reply, not for checksums but for signatures. So you just copy/paste the signature after selecting a file, and then it can verify it's validity.
Is there no such extension yet? it seems like there should be one already.
You could pay for it with some sort of sponsorship from apps themselves, who have an interest in not getting compromised like this (it's terrible publicity).
With digital signatures the problem is that I don't often know who is the official author of the app.
Linux distributions package what is released upstream. If upstream is compromised, so is the Linux package.
Barring a situation where a CDN hosting the download is compromised but the main site is not hosted on the CDN, it's extremely unlikely that someone would have the ability to inject malware into the download and not have the ability to make the checksum match. Posting checksums is actually pretty useless, and was something that used to be used to deal with the possibility of malicious mirrors, but doesn't provide any security against mitm attacks (unless the main site is secure but the downloads aren't which is idiotic by 2016 standards anyway), the site getting hacked, etc.
Digital signatures are a little bit better if the key is kept safe, since hacking the site and replacing the binary won't allow a random person to produce a valid signature, although ability to modify the source code would still allow someone to introduce backdoors into the next version, but there's still a huge problem where you need some way to determine what key was supposed to be used to sign the binary in the first place, so just posting a signature on a website is also basically useless.
Digital signatures can work if there's some sort of centralized distribution method, or for safely updating software that's already installed.
https adds a performance hit. The security of "checksum over https and actual file over http", if the checksum is checked, is the same as "actual file over https", barring preimage attacks.
https://www.whonix.org/wiki/Download_Security
>Practically it is difficult to provide SSL protected downloads at all. Many important software projects can only be downloaded in the clear, such as Ubuntu, Debian, Tails, Qubes OS, etc. This is because someone has to pay the bill and SSL (encryption) makes it more expensive. At the moment we don't have any mirror supporting SSL. We're looking for SSL supported mirrors to share the load.
Is it not true that mirrors supporting SSL are more expensive?
"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that." - Adam Langley, Google
Getting an SSL certificate used to be a cost, but that's taken care of now by https://letsencrypt.org/.
There are multiple named projects there that aren't using SSL, and I don't think it's just laziness. If you know of a way for them to use SSL mirrors for no additional cost, I'll work on getting them to switch over.
I suspect that wiki page you linked might be out of date. It seems like all of the Whonix download links on their website are over https, like the VirtualBox images https://www.whonix.org/download/12.0.0.3.2/Whonix-Workstatio....
Whonix also runs a tor mirror, which has significantly more overhead than TLS.
I seem to remember downloading whonix from their site over HTTP around a year ago.
Do you see a tails HTTPS mirror?
For tails: https://tails.thecthulhu.com/. It appears to be the same server behind http://dl.amnesia.boum.org/ based on the TLS cert.
The situation is messy to actually use https for all of these projects, but I think the issue now is organization rather than overhead.
HTTPS will ensure integrity of your download automatically with no action required from the user.
Checksums require the user to perform the integrity check manually, and 99.9% of users wont bother.
Please don't put your users at risk just to save a negligibly small number of CPU cycles.
> just to save a negligibly small number of CPU cycles
The link above says they can't afford the additional cost. If it's so negligible, would you sponder the cost of those extra cycles? I'm sure they would host on SSL if someone covered the cost.
> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. [0]
[0]: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...
"By default". Most developers don't bother to register, and lots of people change the default (and after that, they can right click to open the app and bypass the warning).
I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.
[0] http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
(There is third party tool named RB App Checker which does make these tasks a bit easier, though)
――――――
¹ — https://en.wikipedia.org/wiki/Installer_(OS_X)
² — http://f.cl.ly/items/1s1E3n19273M1l3i3S2X/developer_id_insta...
“The two KeRanger infected Transmission installers were signed with a legitimate certificate issued by Apple. The developer ID in this certificate is “POLISAN BOYA SANAYI VE TICARET ANONIM SIRKETI (Z7276PX673)”, which was different from the developer ID used to sign previous versions of the Transmission installer. In the code signing information, we found that these installers were generated and signed on the morning of March 4.”
From: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
and that didn't ring any alarm bells?
“And according to the analysis, this is exactly what they did. They used a different cert to sign their malware. I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.”
“Yeah, I think this is a major issue on OS X. For the average user it is impossible to tell who signed an app, if it is sandboxed, and what permissions it has. Hell, using the codesign command to extract entitlements from all binaries in a package is hard even for advanced users... (There is third party tool named RB App Checker which does make these tasks a bit easier, though)”
…in this comment thread: https://news.ycombinator.com/item?id=11234966
[0]: https://forum.transmissionbt.com/viewtopic.php?f=4&t=17835
Many people would uninstall and download it over again when running into that kind of error message.
Given trust in the protection of the private key used to sign the hash list file the integrity of the executable content can be proved (assuming useful SHA1 collision creation is prohibitively expensive).
Coincidentally I was writing a Bash script this weekend to auto-install (Ubuntu) releases into LVM volumes and it includes the following code to verify the download:
It's not idiotic at all. You let anyone who wants to spread the load by providing downloads, but you use checksums - behind https - to ensure they can be trusted.
Doesn't seem like a horrible idea to me: you could just add the developer's key to your client, have your client broadcast interest, receive a _signed_ list of available software with appropriate magnet info... Download servers could serve as initial trackers until enough information has propagated through the network for downloads to be trackerless. Checksums? Guaranteed. Signatures? Acquired. Checking? Performed automagically.
Granted, this just moves the point of failure to the developer's key. (Key acquisition needn't necessarily take place on the developer's site, a friend in the network could pass you a link containing the dev's key and the application's magnet info.)
Debian: have to also fool several people involved in the packaging of said package upstream and everyone using it and building from source
This wouldn't help anyway. If the malicious party had access to alter the downloads (as they did here) they could just as well change the checksum shown on the page to.
>On the other hand, the Windows and OS X App Stores are awful.
Haven't used the Windows one, but what's "awful" about the OS X one? Quick, one click, installations, isolated, signed, easy updates.
Might be bad for the application developers somehow, but I don't see anything much bad about it from a user perspective -- except maybe the lack of trials. Then again I've been able to get a refund any time I bought an app that was subpar and written to Apple (that was 2 times).
Unless you are a small independent app developer. Virtually no distribution wants to take proprietary software. And you have to package for a wide variety of different distributions.
On the other hand, the Windows and OS X App Stores are awful.
The Mac App store works pretty much effortless for me. It's sometimes a bit slow, but other than that it's pretty trivial to use.
I'm game, but I need a little help. What are your favorite techniques for verifying downloaded programs?
But there are a number of things that can be done:
- always verify the checksum (if available), in case the download mirror (but not the web site itself) got compromised.
- check for strange strings in the binary (use "strings" and "grep"). E.g. URLs
- scan the downloaded file on Jotti or VirusTotal.
- unpack the binary manually with 7-zip or similar if it's a self-extracting file.
- check installation scripts, build files, etc. (if applicable).
- if downloading source code, check a couple of files at random. Will most likely not protect you, but if everyone does it, it helps detecting embedded malware (or bugs) early.
- run "strace" (Linux/Unix) or "FileMon" (Windows) or similar software and log what the software does when you install and run it for the first time.
- and check Hacker New regularly ;)
As such, checking the source is still very much relevant here since this wasn't a compromised app in the Mac App Store, it's an app distributed outside it.
- There's no means of providing paid upgrades. E.g. for a major version bump, which a lot of developers rely on to keep their business afloat.
- The store interface and navigation are also much slower than the iOS counterpart.
- Recently some certificate issues rendered users unable to open their apps.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
Apple and other do this by simply numbering the names of apps. They don't allow you to specify special "upgrade" pricing, but the effect of this was that developers no longer really have full retail pricing and everything is just set to the upgrade price.
Logic Pro 8 for instance used to retail at $499. The upgrade price was $199. Now Logic Pro X on the Mac App Store is just $199 regardless of whether you are first time user or someone who had the previous version.
- The store interface and navigation are also much slower than the iOS counterpart.
I haven't really found that the Mac Store is any slower. I've found that they are both slow.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
I don't believe it will even show you newer versions of the apps as long as the developer properly specifies the minimum OS version.
Alas, nobody wants to invest the day or so in actually writing the methods to do it.
EDIT: I downloaded the Transmission 0.90 and 0.91 source code and took a look. The diff between them is quite small, with nothing suspicious being removed, and the 0.90 .tar.xz MD5 matches what Fedora used (according to http://pkgs.fedoraproject.org/cgit/rpms/transmission.git/com...). So, unless there was also a malicious source code change the developer didn't catch, Fedora's package should be clean.
Personally, pending further information, I've removed Transmission from my machine.
[1]: https://launchpad.net/~transmissionbt/+archive/ubuntu/ppa
Same, and I also don't see any `kernel_service` process running.
Fingers crossed for the in-app update not being affected by the hack.
EDIT: welp, BitDefender found nothing, all clear.
――――――
¹ — https://en.wikipedia.org/wiki/Clam_AntiVirus#Mac_OS_X
² — http://clamxav.com/index.html
³ — http://clamxav.com/birthday.html
[1] https://www.malwarebytes.org/antimalware/mac/
Have a trusted machine kept in a secure location to sign it for you if that's practical.
I bet someone's key leaked out here.
>Allow downloading files from http servers (not https) on OS X 10.11+
Mac version affected in OP was 10.10, though.
Maybe it had something to do with
>Change Sparkle Update URL to use HTTPS instead of HTTP (addresses Sparkle vulnerability) ?
Edit: it appears the infection was downloaded from a website, in which case this doesn't help. But one did say the in-app update failed on incorrect signature first.
This reads like they disabled Apple's "App Transport Security", which only allows HTTPS connections unless a program explicitly makes an exception. Introduced in iOS 9 and OS 10.11 (El Capitan). I bet the failing HTTP connections caused a bug in Transmission, and it was an easier fix to disable ATS than to transition whatever connection to HTTPS.
https://developer.apple.com/library/prerelease/ios/documenta...
Pretty sure this is for arbitrary downloads. Unless you want to prevent transmission to download from http based sources out of principle it makes no sense to do anything other than opting out of this behavior.
On the other hand, El Capitan came out last September. If this just changed in 2.9.0, the restricted HTTP connections can't have been that big of a problem.
I'm curious what sort of malware we're looking at. Botnet? General remote access/control? Harvesting keychains?
http://www.cnbc.com/2016/03/06/reuters-america-apple-users-t...
> The malware is programmed to encrypt files on an infected personal computer three days after the original infection, according to Olson.
Anyone who may have been hit, update your backups NOW so you can restore the files.
Safer option would be to create a write-only network share on another computer and copy files to that.
When it comes to checksums with have the chicken egg problem plus the collision attack of md5.
MD5 has been the standard for too long (and is deprecated since 10 years for crypto checksum). And for next generation of softwares to install that don't do modern checksum how can they trust the download of the package required to check for whatever the new format? Plus the new format is less likely to be checked without errors. A off by one character could easily be discarded in checking given the number of packages that are now required to be installed and the human limitation in focus.
Human are the limiting factors, and security is modeling the user in a kind of grotesque caricature of a robot that can check thousands of informations perfectly and remember 20 characters passwords for tens of appliances.
There is a tyranny of computer engineers regarding what is safe for people having a life not concerned about geeky technology that is a tad annoying.
People have the right to be human and to fail is human. The burden put on human to make the system safe in order to avoid costly for the bosses human interactions is way to high.
And since computer security always blame failure on human behaviour I begin to positively dislike it.
You know you can make that complaint about any tool or technology, right?
"Gosh why do I have to follow all these rules and observe traffic lights to drive a car?" (something that actually intimidates me, in fact, because I've never driven a car.)
"Why do I have to worry about cutting or burning myself or someone else while trying to cook a meal?"
"Why are all these procedures and protocols, like schools and banks and taxes, required to function at all in contemporary society?"
Until computers advance to the point of being artificially intelligent familiars that can figure out exactly what we want from a simple vocal command and do something even better, we're gonna have to put in a little effort from our end to make them work the way we want them to.
There are fields of engineering where an accident even due to human causes is systematically seen as an engineering problem.
And that may be the reason why traveling by plane and train are safer than by car.
But US engineers made a great job at convincing legal department that poorly engineered goods where not the causes of accidents.
In those other fields, such as automobiles, an accident by a person may cause death of another.
On a computers your careless may not cause someone else to outright die (which tends to cause a lax attitude on the part of users) but they can still cause someone else harm, like inadvertently leaking someone's financial information or causing malware on your device to participate in a DDOS attack on someone. Time and again it's been proven that users are often the weakest link in this field no matter how tight the security is. It's only understandable for the engineers to be annoyed.
It's good that the Transmission developer reacted quickly and made waves so that people can at least be aware that they might have been exposed..
But I wonder how many more applications from the hundreds that I have installed on my machines contain weird stuff - either intentional (for money) or unintentionally (result of a hack).
Open source software is especially vulnerable to this kind of stuff.
If a hacker gets access to a server holding the binaries for an open source app (which most people download), the hacker can just compile the program from sources and add his own code in there and place the installer online.
Given that many big governments are now involved in the information wars, this scenario is quite likely.
I am sorry, what? Why would open source contain more bugs/hacks than closed source specifically? It is more often in the news for few reasons, including that many projects are widely used. However it's against any PR from companies to have their security issues disclosed like they are in open source so they try to minimize the exposure. See [1]
[1] http://www.techrepublic.com/article/open-source-vs-proprieta...
SourceForge has been linked to bundled malware and hijacked projects like GIMP and FileZilla.
Code signing is used to prevent this. So, either the attacker has an Apple developer account (and is hopefully traceable through their credit card information), the Transmission project was sloppy with their signing key, or the machine of the developer with the signing key was compromised.
People have been ranting negatively about the Mac App store. But this is exactly why we need sandboxed applications by default (which is what the Mac App Store enforces). A sandboxed application cannot take your data hostage.
(Yes, I understand that App Store distribution is probably not possible for a Bittorrent Client.)
Sorry, I forgot another possibility: some other developer's key was compromised.
“The two KeRanger infected Transmission installers were signed with a legitimate certificate issued by Apple. The developer ID in this certificate is “POLISAN BOYA SANAYI VE TICARET ANONIM SIRKETI (Z7276PX673)”, which was different from the developer ID used to sign previous versions of the Transmission installer. In the code signing information, we found that these installers were generated and signed on the morning of March 4.”
From: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
http://www.bloomberg.com/research/stocks/private/snapshot.as...
So, it could be that the malicious part was not issued a key, but stole the key from this company.
So I think sandboxing is basically useless against these kinds of attacks. Either they allow apps to elevate their entitlements in an update, or they don't and developers will always out-out from the start (or pick the widest set of entitlements available).
If sandboxing is forced with no opt-out, then users will have to jailbreak their computers so they can install Parallels...
There is no such entitlement:
https://developer.apple.com/library/mac/documentation/Miscel...
If you are talking about the 'open directory' dialog. Well, if a user is careless enough to just give a sandboxed app access to their complete home directory - tough luck.
So I think sandboxing is basically useless against these kinds of attacks.
No, it's not, because no entitlement allows blanket access to the user's home directory. Hence, an application cannot just encrypt all of the user's data.
I'm not sure I follow on this front. Proprietary software could be compromised (whether intentionally by the vendor or unintentionally by some outsider working on the software) effectively forever with no one noticing. At least with OSS, the number of eyes on the source makes it less likely that an exploit will exist for long (though the definition of "long" could vary wildly dependent on popularity and the skill level of the software's normal users).
"Given that many big governments are now involved in the information wars, this scenario is quite likely."
Again, this one seems to point more to proprietary software then OSS. A government only needs to compromise a single company to make an exploit happen in commercial software. OSS exploits can be caught by the Linux distribution vendors that package the software, the users, the developers themselves (who are often working at different companies and in different nations), etc.
So, it may seem easier to compromise an OSS project, by attacking the distribution server and uploading a compromised binary built from source with patches...but, there are many good ways to guard against that (though any single mitigation, like signing with developer keys, can be compromised, the more eyes the less likely it is to succeed for long). But, if a government compromises a company, or someone within that company, all bets are off, and the problem literally may never be found.
The risk is not in the sources, but in the server which hosts the installers. A hacker could just build the software from sources (adding his backdoor) and replace the original installers with his own.
You must be too young to remember how computer viruses originally spread by way of modified executable files: http://computervirus.uw.hu/ch04lev1sec2.html
Patching is possible, but why bother when you can compile the app from sources?
Nice book btw.
Well, imagine that you are the attacker here. Would you rather keep your malware source in sync with the upstream code and build every target every update, or just use an off the shelf binary wrapper. Would you answer the same if you were targeting more than one app (in the case of a CDN attack)?
The only scenario in which source level malware makes sense to me is this: you are targeting a specific application and you are able to get your code into the project's SCM. In this scenario OSS is no more vulnerable than closed source.
Give it 2 or 3 years and stories will come trickling out about how most OS apps have had commits from hackers, governments etc. So far most source checking - to the extent that it happens at all - is all about buffer overruns and the like; micro stuff that's easily catchable. Well, you say that, but, you know, heartbleed etc. But what about whole modules designed with two purposes in mind?
All software is vulnerable to bad actors writing malicious code. What makes it any safer if its proprietary software? In any case, in a pessimistic scenario you'd have to change your sentence to "give it 2 or 3 years and stories will come trickling about how ALL apps, open or closed source, were tampered with by hackers, the government, etc".
> Give it 2 or 3 years and stories will come trickling out about how most OS apps have had commits from hackers, governments etc. So far most source checking - to the extent that it happens at all - is all about buffer overruns and the like; micro stuff that's easily catchable. Well, you say that, but, you know, heartbleed etc. But what about whole modules designed with two purposes in mind?
Free Software has existed for over 20 years. Not to mention the fact that the same problem you describe is far more trivial for proprietary software. There's no straightforward way to find out if it's backdoored (although, luckily quite a few backdoors are done badly so we can find out). The point is that if you assume that all free software is compromised, you have to assume all proprietary software is compromised. I'd prefer to have some free software be compromised because then I'm not at the mercy of the vendor to fix it.
[1]: https://en.wikipedia.org/wiki/Transmission_%28BitTorrent_cli...
http://www.cnbc.com/2016/03/06/reuters-america-apple-users-t...
- It's Ransomware.
- Seems to be a 3 day grace-period (chance to remove it, possibly).
- The Transmission developer certificate [Gatekeeper] has been revoked.
https://www.virustotal.com/en/file/d1ac55a4e610380f0ab239fcc...
(Look under the "Behavioural information" tab)
Written Files and Created Processes are interesting:
[Transmission] /Users/user1/Library/kernel_service (successful)
[unknown] /Users/user1/Library/.kernel_pid (successful)
[unknown] /Users/user1/Library/Saved Application State/org.m0k.transmission.savedState/window_1.data (successful)
[Transmission] /Users/user1/Library/Saved Application State/org.m0k.transmission.savedState/data.data (successful)
[Transmission] /Users/user1/Library/Saved Application State/org.m0k.transmission.savedState/windows.plist (successful)
[kernel_service] /Users/user1/Library/.kernel_time (successful)
Created processes
/Volumes/Transmission/Transmission.app/Contents/MacOS/Transmission (successful)
/Users/user1/Library/kernel_service (successful)
kernel_service (successful)
Edited to add: If anyone has a copy of the DMG, sha1 5f8ae46ae82e346000f366c3eabdafbec76e99e9, please link me a copy via email (brendandg@nyu.edu) or twitter DM (@moyix).
Why should it? For open-source software build-server can even be ran by a third party.
As far as I know, only the binary was updated.
I'd be interested to hear, though, how it got compromised after all.
https://reproducible-builds.org
And even if you sign updates, the key management for doing that is usually centralized, which can be bad:
http://arstechnica.com/security/2016/02/most-software-alread...
[1]: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
Jenkins (and CI in general) can be a very weak point. This was posted on Hacker News a while back https://github.com/samratashok/ContinuousIntrusion
How to Protect Yourself
Users who have directly downloaded Transmission installer from official website after 11:00am PST, March 4, 2016 and before 7:00pm PST, March 5, 2016, may be been infected by KeRanger. If the Transmission installer was downloaded earlier or downloaded from any third party websites, we also suggest users perform the following security checks. Users of older versions of Transmission do not appear to be affected as of now.
We suggest users take the following steps to identify and remove KeRanger holds their files for ransom:
1. Using either Terminal or Finder, check whether /Applications/Transmission.app/Contents/Resources/ General.rtf or /Volumes/Transmission/Transmission.app/Contents/Resources/ General.rtf exist. If any of these exist, the Transmission application is infected and we suggest deleting this version of Transmission.
2. Using “Activity Monitor” preinstalled in OS X, check whether any process named “kernel_service” is running. If so, double check the process, choose the “Open Files and Ports” and check whether there is a file name like “/Users/<username>/Library/kernel_service” (Figure 12). If so, the process is KeRanger’s main process. We suggest terminating it with “Quit -> Force Quit”.
3. After these steps, we also recommend users check whether the files “.kernel_pid”, “.kernel_time”, “.kernel_complete” or “kernel_service” existing in ~/Library directory. If so, you should delete them.
It's fascinating!
https://en.wikipedia.org/wiki/Command_and_control_%28malware...
I just learned that too. For me, C&C reminds me "Command and Conqueer" (the game).
https://en.wikipedia.org/wiki/Command_%26_Conquer
Analysis: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
They ask (only) 1 BtC as a ransom.
Screenshots of the web UI:
https://twitter.com/moyix/status/706577507965870080/photo/1
[1]: https://twitter.com/claud_xiao/status/706563279355645953
I've just been looking at BitDefender, which looks promising, but would rather get this right than faff around with potentially crappy AV tools.
Common Sense 2016, see https://github.com/drduh/OS-X-Security-and-Privacy-Guide
Nevertheless, I still believe Common Sense to be a better alternative to bloated, vulnerable anti-virus programs.
Ironically I decided to use the good, ol', trusted open source alternative transmission because I just read on HN that Transmission gets updated again...
1: https://github.com/caskroom/homebrew-cask/issues/19504#issue...
2: https://github.com/caskroom/homebrew-cask/pull/19506
3: https://github.com/caskroom/homebrew-cask/pull/19508
When you can't (be bothered to) vet the source code, stick it in a vm. On a sensible machine with an ssd it's only 10 seconds away. Why risk it. Especially if the software you want/need to run only works under windows.
The way I see it, they're more secure that running the same apps on bare metal. Ubuntu host running a Fedora VM; the latter (with Transmission etc) only running when I need the apps running - seems an almost entirely painless way of providing a lot of security.
* http://arstechnica.com/security/2015/05/extremely-serious-vi...
* http://www.securityfocus.com/archive/1/495095
* https://www.cert.be/advisories/oracle-vm-virtualbox-two-priv...
* http://www.coresecurity.com/content/virtualbox-privilege-esc...
Lets try to avoid treating security as something binary.
VMs have tons of well documented issues. If you want a smaller attack surface, try OS virtualization technologies (zones/jails)
It should be able to sandbox Windows Apps, except for Metro/Modern UI Apps and Microsoft Edge.
Too many programs are having a backdoor or Trojan in them now. It is a good idea to run any app that accesses the Internet in a sandbox first to see what it does.
http://www.cameyo.com
And they have prepackaged sandboxed apps:
https://online.cameyo.com/public
It isolates the process, all writes (filesystem, registry) go to the sandbox instead of the host filesystem, so a malicious software can't easily install itself. But reading data is mostly unprotected by default, so a malware ran in a sandbox may steal some sensitive data. To protect such data you have to pre-configure sandbox manually.
Note that I've only used it to run Linux so far.
Neat. Never heard of this one before - what makes it special?
But still, this is about malware in Transmission itself, not anything downloaded using it. So the fact that it's a BitTorrent client is rather beside the point, I think.
[1] - http://www.reuters.com/article/us-apple-ransomware-idUSKCN0W...
[1] = https://sparkle-project.org/documentation/security/
[2] = https://trac.transmissionbt.com/log/tags/2.92/macosx/Sparkle...
Perhaps a defense against this kind of attack would be an altered version of HSTS - one that protected the content of download links, and not just of sub-resources included on the page.
Just because attackers can break out of VMs, doesn't mean that they always do. I wager most malware out there isn't set up to do that.
Locking your car door won't keep a dedicated attacker out of your car. Simple ceramic shards from a sparkplug will get them through the window with barely any effort at all. Nevertheless, locking your car doors is an effective way to reduce your risk, as it dissuades more opportunistic attackers.
> from Greek analogia "proportion," from ana- "upon, according to" (see ana-) + logos "ratio," also "word, speech, reckoning" (see logos). A mathematical term used in a wider sense by Plato.
http://www.etymonline.com/index.php?allowed_in_frame=0&searc...
> [...] from properly feminine of λογικός (logikós, “of or pertaining to speech or reason or reasoning, rational, reasonable”), from λόγος (lógos, “speech, reason”).
https://en.wiktionary.org/wiki/logic
There is no analogy without logic. I even fail to recognize a difference between speech and logic, speech without logic, by analogy, would be just noise.
The facts that the english word analogy descends in a complicated manner from a greek word referring to mathematical proprotions, and the english word logic descends in a somewhat less complicated manner from a greek word referring to speech, and that those greek words shared their pronunciation, tell us nothing about the relationship between analogies and logic.
A standard chinese term for "analogy" (also, "metaphor") is 比喻 biyu. The term for "logic" is 逻辑 luoji (it is a loan word from english). Are you prepared to grant that, while analogies and logic are necessarily intertwined for people who speak english or greek, they are unrelated for people who speak modern mandarin chinese?
No linguistic reasoning is needed however, to see that an analogy essentially needs logic to work in any language. It helps however. EG in English tongue still language in an idiomatic metaphorical sense, analog to the original meaning of logos, tongue, metaphorically referring to speech.
My argument is not ignorant, anyway, it's arrogant.
Αναλογία means the comparative association of two (antithetical) objects in quantity, size, etc.
Λογική means to reason with a basis in reality.
I stand by "extremely ignorant".
Someone who doesn't even understand that and that the linguistic argument is of the table, and still keeps going, shouldn't try to talk about logic, as right as some of the individual arguments might be. Ana-logically, I shouldn't be writing any more about this.
Sure. That's why sometimes we see such bad analogies, the logic doesn't match so well the actual idea. When the idea you are trying to convey isn't that complicated at all you're probably better off using just pure logic and not complicated constructs such as analogies.
As for speech, indeed, there's a deep logic bounding the language structures we use. The problem with language (logic and meaning wise) is that language is relative to the environment and to the speakers of the conversation. You have to figure out the "language game" where the conversation is being held. As for logic, we expect no subjectivity (if there is subjectivity it's bad logic).
So clone the last release version you trusted, build that from source and be happy?
The current version could be being compromised this minute for all we know.
Transmission was and remains my favorite torrent client on OS X, although I still like the torrent information presentation uTorrent had, and I still will run my old pre-adware 1.6.4 if I want more detail on a swarm.
Given that older versions still work, it seems exceptionally silly to delete an old version because of a site compromise.