Audacity was also affected: http://www.audacityteam.org/hacked-download/
Fun fact: We actually had an EFI payload. We just had issues with the installer and it was left unadded.
UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
is an ancient African word meaning "Why do something right when you can
do it so wrong that children will weep and brave adults will cower before
you", and "UEI" is Celtic for "We missed DOS so we burned it into your
Laptops are another story.
Would’ve been funny to see what they’d have done with EFI – maybe a graphical message?
Anyway, the only way to solve these issues in the long-term is with relying more on signed software, similar to how Linux repos work already today.
It seemed as though Windows was warning the users that the software was unsigned; they just clicked through it. That's a different problem -- it's entirely possible to have a signing system, but if enough developers hate and refuse to use it, then users will quickly become conditioned to click through the warnings.
I'll be honest: if there was an app that I wanted to install, and I got an unsigned-package warning, my first thought on both Mac and Windows would be that the developer probably had an ethical or financial problem with the signing scheme, not that the package was compromised. On Linux, I'd be more confident and probably stop what I was doing, but only because very little software makes it onto distribution systems if the developer has an issue with the platform...
And it does work in this case - try googling both the published good and bad hash :)
It wipes the MBR, but no other data. The MBR isn't that hard to recover.
Presumably you could do the same thing these days with any USB flash drives that had been left plugged in.
It's described there as the Audacity portion being a compromise of an Audacity developer's account, with another reference to two compromised accounts. There were also other attack attempts going on at the same time, so the FossHub folks took things down for a time - not sure if they're done with their checking or not.
According to FossHub there were only ~300 downloads of Classic Shell during this time, and they may have caught the Audacity one faster.
File size: 7220496 bytes
File size: 7148732 bytes
So it's still good for identifying files that aren't specifically crafted to have a malicious counterpart.
So, I'd say this is safe, for now. Yet, I also get bad feelings when somebody either comes with an MD5 hash or uses a SHA-1 as the most secure option.
So if they were gonna put effort into making an sha1 collision, they'd probably target the signed payload, not the overall exe.
Though it doesn't look like sha1 is that broken yet, for the budget of this grade of attacker.
There's nothing like HSTS for signed programs, so it can't be helped, though.
>When I installed it said it couldn't be trusted, I installed anyway but it did nothing.
Users have no way of knowing which things are safe and which things aren't if almost everything comes with a "this isn't safe" warning.
Then build out a reputation system for signers. I was recently given a link via steam to watch a video. It had an embedded fake Flash updater. The installer was very clever as it was signed by something like "Browser Company" and looked like the official Flash installer. My local AV and virustotal.com didn't detect it at the time either.
I think the age of it being convenient to run arbitrary executables in Windows is ending. There's just too much liability now, especially in the age of ransomware and kiddie hackers doing it for the lulz.
Moving on, I've been thinking about the problem of file integrity and how verifying the MD5/SHA sum creates extra gruntwork for the end-user, particularly for your average Windows user.
How difficult would it be for the installer to compute its own hash and present it to the end-user when the installer starts, so that they can verify it against the hash posted on the front of the software's webpage?
EDIT: Although I suppose if the binary itself is compromised, the hackers could always modify the hash function so that it shows the same hash as an existing "good" version even with the malicious code added. Hmm.
"To be safe, always check the digital signature of EXEs you downloaded, before you run them. The official Classic Shell installer has a signature for "Ivaylo Beltchev", and the fake one doesn't even have a signature."
And per another user (silmar), my sentiments:
"The problem with signed installers is: many software developers don't sign, so you install even if Windows warns you. Even if someone signs and then stops signing, it may be that he forgot about it. But you want to install NOW, so you skip the warning."
Admittedly the download page doesn't mention signing or how to look for that, though, per the comment I referenced above, I doubt it would make much difference to the vast majority of users.
While I'd like to think things are generally better now, I think the historical inertia of Windows' ecosystem and how conditioned users have become to ignoring such warnings is at least partially (mostly?) at fault. There's no easy way to correct people's behavior, and enforcing certain settings (e.g. only installing signed software) would mean either 1) upsetting power users or 2) users still finding a way to disable such checks.
I'm currently rather thinking about some cross-referencing service. A developer would go ahead and register multiple download locations for their product. The system would go ahead and download the file from the various locations, compute checksums and alert if the checksums of different download locations differ.
If this service exists, you'd have to compromise this service and a download location in order to exchange a file unnoticed for more than 2*the check interval.
The major issues I see:
- Updates are a big issue, because updates are a planned exchange of the binary to download. So I guess there'd need to be a set of valid checksums, which weakens the guarantees of the system, but not too much.
- Resources are an issue, especially bandwidth and traffic. Imagine getting all debian isos from all mirrors to verify their checksums.
But either way, such a service could be a good way to detect irregular file changes and notify the security community, devs, site admins and so on.
Nothing really stops you from unpacking all of the contents of the first installer, and repacking it with your payload into an unsigned installer which is likely what happened here.
Or worse tells them to download an unknown program which turns off a bunch of security features at a single click without an explanation of the cost. But at least the user feels less spied upon or something...
Here's a video where the malicious file is executed. Nothing immediately seems amiss: https://youtu.be/DD9CvHVU7B4?t=1m43s
Here is what SmartScreen actually looks like and actually does on Windows 10 when attempting to download an unsigned installer.
If Microsoft is aware that the file you're attempting to download is malware, they will block the download entirely (in IE/Edge).
I know several large FLOSS projects, with hundredthousands and millions of users, that ship only unsigned binaries, telling their users to turn off SmartScreen.
If Microsoft would have used a GPG-like mechanism, or provided certs for free, it would look very different.
OS X doesn't have this problem usually, as most apps don't require admin rights to install, you just copy them to /Applications, but it still has some apps that use installers.
But everyone "hates" UWP apps so....
/Applications requires administrative rights to update. I never use an admin account for every day activity, so I need to type in a password to update /Applications.
Disclosure: I'm not a mac user, and never have been one long enough to mess around with /Applications.
Obligatory xkcd: https://xkcd.com/1200/
That doesn't help you with apps you downloaded through the web though, which for me is all my apps because the App Store is a PITA.
Close one for me: I was downloading WinDirStat when I came across that post.
Looks like I wasn't affected. There was an official update (4.3.0) which was released on the 30th leading to unfortunate timing.
They had the power to abuse that data and ship malware to millions, but decided just to give people a scare.
That’s just the average grey-hat, or how most hackers were in the 90s.
Compared with the profit-obsessed and abusive hackers and companies on the web today, which try to shove actual malware, sometimes installers with tons of preselected options, sometimes bitlocker, they’re not bad.
Deleting the partition table is not grey hat, it's black hat. The bad guy in a Western isn't suddenly neutral just because he isn't literally Josef Stalin.
Linking may not imply endorsement but their twitter account clearly shows they want the public hate as attention, so whether you want it or not, you're doing them a favour by naming them, even if to scold them.
This is akin to associating every mass killing with a terrorist organisation (whether accurate or not) and showing detailed videos of those killings when the entire point of a terrorist organisation is spreading terror.
Warning: Certain audio editing software and system customization tools may be incompatible with Razer firmware.
A new ClassicShell update was released to patch incompatibilities with Razer hardware! Download it at http://classicshell.net
To anyone upset: At least we didn't decide to steal all your shit. Because you ran that as admin. We totally could've installed a rootkit.