Handbrake Developers Issue Mac Security Warning After Mirror Download Server Hack

[Quu]

They can't publish GPL / Open Source titles in the Mac App Store as Apple's terms and conditions violate open source rules.

Apple would need to provide a separate open source section that doesn't require the downloaded to agree to any of Apple's terms and conditions.

A good brief explanation can be read here:

http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement

I'm aware of this already, I'm a developer myself. I wasn't referring to the Handbrake developers, I was speaking to all the developers that this keeps happening to over and over again even when it's a closed source app that could be put on the App Store but the developers choose not to.

 

[modemthug]

If you rely on the suspicion system of security it is only a matter of time before you get hosed. These hackers are good at looking not suspicious, and the meaning of these dialog boxes is far from clear, making it close to impossible for most users to tell one that's legitimate from one that is not.

I don't think he/she is saying to rely only on a system of suspicion but rather to be vigilant

 

[Westside guy]

That said, I'm posting because I nearly got caught by this.

It's also another reminder that it's better for your day-to-day account to not be an admin account. OS X / MacOS make it trivially easy and painless to run as a non-admin user.

If your username is "joe", just create a new account "joe_admin" with a different password, then log into that account and remove admin permission from your original account. Really the only things that change is a) the admin prompt text changes from "enter your password" to "enter an administrator's name and password"; and b) you'll have to type the admin account name (e.g. "joe_admin") and password instead of just typing in a password. Easy peasy.

 

[Rigby]

It's pretty sad to see history repeat it self again... Much like the inept developers of Transmission BitTorrent. These devs likely reject the best practice of cryptographically signing their releases because they either don't care or don't even know how to use PGP.

Of course they are aware of this.

Why don't you donate $260 to the project? That's what another well known open source project recently paid for a signing certificate that is recognized by Windows and MacOS.

 

[bladerunner2000]

what a non-sensical name and even more confused icon for a tool that transcodes video. why can't people name and iconify things anymore that actually indicates what they do in some small part?

It's a nice break from the sterility of everything Apple.

 

[groovyd]

It's a nice break from the sterility of everything Apple.

Guess it's an indication that using the tool won't make any sense either... fair game.

 

[DENZIE]

Handbrake users should note that the primary download mirror and the Handbrake website were unaffected by the hack. Downloads via the application's built-in updater with 1.0 and later are also unaffected, since these are verified by a DSA Signature and won't install if they don't pass.

This is not true for me. I confirmed this morning that my mac was infected after installing from the dmg downloaded from the download link presented on the main handbrake website. On launching the old version of the code night of May 3, the auto-update feature prompted 1.0.7 was available but the install failed twice so I manually went to the handbrake website to get the latest version.

First time I've used handbrake in ages so this totally sucks!

 

[Rustus Maximus]

Maybe I overlooked it, but were their 'Nightly Builds' affected by this?

 

[bladerunner2000]

Guess it's an indication that using the tool won't make any sense either... fair game.

The app is one of the best out there. I use it almost daily.

 

[IJ Reilly]

I don't think he/she is saying to rely only on a system of suspicion but rather to be vigilant

But vigilant of what, and how? This situation is a perfect example of where ordinary vigilance fails. To me this sounds like the first step towards blaming someone who gets screwed by installing software they had every reason to assume was legitimate on user error.

 

[Floris]

But vigilant of what, and how? This situation is a perfect example of where ordinary vigilance fails. To me this sounds like the first step towards blaming someone who gets screwed by installing software they had every reason to assume was legitimate on user error.

I almost got caught by this. I have not updated handbrake in ages, and the other day I was going to archive some of my dvds and decided to open it. It told me it was too outdated for the version I was running now and required an update. I decided oh well, forget about it. Seemed like a hassle. Then day later I read this news going "phew". +1 for being lazy

 

[thomasareed]

It's important to note that hashes are an extremely flawed method of verifying the legitimacy of an app. If a hacker has managed to replace the app on the website, it's not a stretch to imagine that they have also replaced the hash on that same website.

Not to mention that an SHA1 or MD5 hash cannot be considered to be a guarantee, since it is now possible to create different files designed to have the same hash. All it takes is processing power, and the power needed can be easily purchased from Amazon, or obtained by a hacker by employing an existing botnet.

Code signing is the only way to guarantee that the app has not been tampered with, and HandBrake is not code signed. So it's really very difficult to determine whether you have an un-tampered copy of the app.

Some have pointed out that Apple developer certificates can be purchased for $99, and used to sign a malicious version of an app. This is true, and it's been done. That's what happened in the case of Transmission's hacks. However, this is an easier issue to spot, if you know how, as the code signature will change. If the app is signed with a cert belonging to someone other than the developer, you know there's a problem.

Of course, the average user won't know how to check that - or even that they should - any more than they'll know to check a hash.

Those asking how they can trust HandBrake again are asking a good question. It's particularly concerning that there is a historical connection between Transmission and HandBrake. I don't know how many people may have access to both projects, but these repeated hacks start to seem like an insider job. Without code signing, there's really no way we can be expected to trust HandBrake in the future.

(Fortunately, I only have HandBrake installed on an older Mac with no PII... but even so, this is something that could have infected my Mac, and I'm a security researcher!)

 

[Ritsuka]

It's important to note that hashes are an extremely flawed method of verifying the legitimacy of an app. If a hacker has managed to replace the app on the website, it's not a stretch to imagine that they have also replaced the hash on that same website.

Not to mention that an SHA1 or MD5 hash cannot be considered to be a guarantee, since it is now possible to create different files designed to have the same hash. All it takes is processing power, and the power needed can be easily purchased from Amazon, or obtained by a hacker by employing an existing botnet.

Code signing is the only way to guarantee that the app has not been tampered with, and HandBrake is not code signed. So it's really very difficult to determine whether you have an un-tampered copy of the app.

Some have pointed out that Apple developer certificates can be purchased for $99, and used to sign a malicious version of an app. This is true, and it's been done. That's what happened in the case of Transmission's hacks. However, this is an easier issue to spot, if you know how, as the code signature will change. If the app is signed with a cert belonging to someone other than the developer, you know there's a problem.

Of course, the average user won't know how to check that - or even that they should - any more than they'll know to check a hash.

Those asking how they can trust HandBrake again are asking a good question. It's particularly concerning that there is a historical connection between Transmission and HandBrake. I don't know how many people may have access to both projects, but these repeated hacks start to seem like an insider job. Without code signing, there's really no way we can be expected to trust HandBrake in the future.

(Fortunately, I only have HandBrake installed on an older Mac with no PII... but even so, this is something that could have infected my Mac, and I'm a security researcher!)

Thanks for the baseless speculations on the server part.
By the way, the hash is SHA256 and available both on the handbrake website and GitHub.

 

[thomasareed]

Thanks for the baseless speculations on the server part.
By the way, the hash is SHA256 and available both on the handbrake website and GitHub.

I never said that the idea of an insider wasn't speculation - that seems clear from my wording - however I wouldn't call it baseless. It's hard to imagine that it's coincidence that the only two Mac apps that have ever been hacked to spread malware in exactly this manner have a historical commonality. Whether it's an insider or not is irrelevant, but there certainly seems to be something about these projects that lends to them being easily hacked.

As for the hash, yes, there's an SHA256 hash available as well as an SHA1 hash. That's beside the point. The point is that there are very good reasons not to trust hashes as a means for verifying an app's authenticity, as a general rule.

 

[ibookg409]

So is it saf to download NOW?

 

[Nunyabinez]

Did no one actually read the article? It seems like rather than read the article people prefer to jump to conclusions or ask someone else to splain it to them.

On only one out of multiple server mirrors, for only a few hours, the new installations of handbrake had a 50/50 chance of being infected.

Now maybe all 10 of them should freak out. The rest of you who already had it installed, or updated internally, or downloaded it from their other servers can take a chill pill.

 

[DogHouseDub]

Will Sophos antivirus catch things like this?

 

[BC2009]

I lucked out on this one. I downloaded and installed on May 4th. I realized that I had not installed handbrake on my new MacBook and figured I would. I fell in the 50% that got the uninfected DMG file.

 

[thomasareed]

Did no one actually read the article? It seems like rather than read the article people prefer to jump to conclusions or ask someone else to splain it to them.

On only one out of multiple server mirrors, for only a few hours, the new installations of handbrake had a 50/50 chance of being infected.

You must be reading something different than I am. According to the security advisory posted on the HandBrake site:

https://forum.handbrake.fr/viewtopic.php?f=33&t=36364

Anyone who has downloaded HandBrake on Mac between [02/May/2017 14:30 UTC] and [06/May/2017 11:00 UTC] needs to verify the SHA1 / 256 sum of the file before running it.

Anyone who has installed HandBrake for Mac needs to verify their system is not infected with a Trojan. You have 50/50 chance if you've downloaded HandBrake during this period.

So, statistically speaking, half the people downloading from the HandBrake site during a four day time period (not a few hours) will have gotten the malicious app. Although this is not mentioned in the security advisory, the issue also affected the installation of HandBrake via homebrew.

As to how many people were affected, we have no way to say, but I'd wager that's far more than 10 people, unless HandBrake's popularity has waned significantly and I'm not aware of that.

 

[manu chao]

It's also another reminder that it's better for your day-to-day account to not be an admin account. OS X / MacOS make it trivially easy and painless to run as a non-admin user.

If your username is "joe", just create a new account "joe_admin" with a different password, then log into that account and remove admin permission from your original account. Really the only things that change is a) the admin prompt text changes from "enter your password" to "enter an administrator's name and password"; and b) you'll have to type the admin account name (e.g. "joe_admin") and password instead of just typing in a password. Easy peasy.

I am not disagreeing, I am just curious what exactly a piece of malware can do on an admin account that it cannot do on a non-admin account given that Apple ring-fences a lot of things with these password requests anyway? Certainly, the most obvious difference is that you have to know the password (and username) of an admin account if your main account is a non-admin account. Thus you can protect your computer from other users' mistakes, but that won't protect against your own mistakes. To make rephrase, what can you do on an admin account without entering your password that could not do on a non-admin account without entering a password?
[doublepost=1494259324][/doublepost]

Will Sophos antivirus catch things like this?

In time, it should.

 

[thomasareed]

It's also another reminder that it's better for your day-to-day account to not be an admin account.

That's an over-rated precaution, and it would have done nothing whatsoever in this case. The malware installed all components in user-space, which requires no admin password, and its primary goal appears to be exfiltration of data that can mostly be found in - or read by - a standard user account. The password needs not be an admin password... it just needs to be the user's password so the hackers can decrypt the exfiltrated keychain file.

So, basically, you'd be just as screwed in a standard user account as in an admin account. The same has been true of numerous other pieces of malware over the years. Admin privileges are not required for malware to ruin your day. Ransomware does not need an admin password to encrypt all your documents, and malware does not need an admin password to exfiltrate those documents.

There can be some good reasons to run in a standard user account, but don't make the mistake of believing it makes you safe from malware.

 

[Westside guy]

I am not disagreeing, I am just curious what exactly a piece of malware can do on an admin account that it cannot do on a non-admin account given that Apple ring-fences a lot of things with these password requests anyway?

If I have your (admin-level) password, I can write many important places in your file system without invoking that prompt. I can replace an application, in part or in whole, for example.

The thing to consider is the graphical interface is not the entire operating system. Apple is, over time, continuing to tighten up security - but it is still the case that an admin user has write access to files and directories which a non-admin user does not. Sometimes this requires invoking "sudo" (the terminal-level equivalent of the admin password prompt), and sometimes not - but if they've managed to get your password and you're an admin, even that can be managed silently. Non-admin users do not have sudo access by default.

Unix systems have been managed this way for decades.

Nothing is perfect; but not running under an admin account adds another layer of security with very little pain.

 

[thomasareed]

If I have your (admin-level) password, I can write many important places in your file system without invoking that prompt.

That is true. It's also true that malware does not need to bother with any of that to be effective, as I pointed out. There are many specific cases in which Mac malware made no attempt to gain admin privileges, and did not need to.

If you want to use a standard user account, then as I said, there can be good reasons to do so. But if you do so in the belief that it will make you safe from malware, you will have a false sense of security and may learn how wrong you are the hard way. As an extra layer of security against malware, this one is quite weak.

 

[manu chao]

If I have your (admin-level) password, I can write many important places in your file system without invoking that prompt. I can replace an application, in part or in whole, for example.

When I use a non-admin account on my own computer, I also know the password for the admin account. And thus if something asks me for an admin password, I can type that in regardless of whether I am currently using a non-admin or an admin account.

The thing to consider is the graphical interface is not the entire operating system. Apple is, over time, continuing to tighten up security - but it is still the case that an admin user has write access to files and directories which a non-admin user does not. Sometimes this requires invoking "sudo" (the terminal-level equivalent of the admin password prompt), and sometimes not - but if they've managed to get your password and you're an admin, even that can be managed silently. Non-admin users do not have sudo access by default.

And pray tell, how would they get my (admin) password? By bringing up a password dialogue that requires me to type in my (admin) password. That part is the same single point of failure regardless of whether I am using an admin or a non-admin account.

Nothing is perfect; but not running under an admin account adds another layer of security with very little pain.

Sure, but what I am asking is what exactly this difference is? What directories exactly can an admin user application (ie, something that a trojan tricks you into launching/opening) write to without asking for an admin user password entry that a non-admin user application cannot?

Given what I have read about this piece of malware, selecting a different password for your keychain than your user account login password, seems to be at least as useful. But strangely enough, I hear advice about using a non-admin user account 100x more often than advice about using different passwords for user account and keychain.
[doublepost=1494263577][/doublepost]

If you want to use a standard user account, then as I said, there can be good reasons to do so.

One straightforward one is that you can prevent other less scam-proof users of your computer from entering an admin password.

 

[Rigby]

Sure, but what I am asking is what exactly this difference is? What directories exactly can an admin user application (ie, something that a trojan tricks you into launching/opening) write to without asking for an admin user password entry that a non-admin user application cannot?

One example is the /Applications directory. When you're running under an admin account, everything that you execute can e.g. replace or modify your installed application executables without any password prompt. This can be used e.g. to make malware persistent. You can try it yourself: open a terminal while logged in to an admin account and type "touch /Applications/xxxx". You will not see any prompt an the file will be created. If you try the same under a standard user account, you'll get "permission denied".

Given what I have read about this piece of malware, selecting a different password for your keychain than your user account login password

That is a good idea. Also, be mindful what you store in the keychain in the first place.