Hacker News new | comments | show | ask | jobs | submit login
Classic Shell hacked with compromised update that erases your partition table (classicshell.net)
175 points by megalomaniac443 on Aug 3, 2016 | hide | past | web | favorite | 105 comments



It looks like this is on Fosshub (at time of writing is offline) which could imply that there's a much larger compromise in progress depending on what popular software is hosted there.


It looks like they have a dump of the Fosshub user database.

Audacity was also affected: http://www.audacityteam.org/hacked-download/


In FossHub statement on reddit they said that they think they got credentials that were saved inside Redis through probably a zero day exploit. Probably something to be verified


Damn. You have no idea how close I was to reinstalling Audacity last night.


Downloaded it a couple days ago in my case! Close call, though I do backup my important files offsite.


I keep two offsite backups!


It sounds to me like one or two people reused passwords between fosshub and some other site that had its database breached.


I also hate that Fosshub doesn't even use HTTPS, even though they could get a Let's Encrypt certificate for free. They only offer file signatures, but even those are MD5 and SHA1, and both types should've been deprecated a while ago.


I don't see much value in published file hashes when they're hosted on the same site that hosts the files. If someone compromises the download link they're probably in a good position to update the hashes too.


The purpose of the hashes isn't to prove the file hasn't been tampered with, its confirm that the file wasn't corrupted during download.


Then just use checksum instead of an obsolete cryptographic hash.


Interesting to see malware in this day and age that actually kills your computer instead of installing adware or joining a botnet.


From their Twitter page

Fun fact: We actually had an EFI payload. We just had issues with the installer and it was left unadded.


Damn. With the state of most consumer mainboards, an EFI "payload" could leave the system "bricked". I know I've got one el-cheapo laptop that can't boot because I made a mess of the EFI environment and there's no way to reset it.


I'm begin to think that EFI is a very wrong turn way on modern computers.


You're a bit behind the curve on this. EFI has been criticized for being horrendously complicated and gross since its inception.


Obligatory Matthew Garrett quote from a Linux kernel EFI patch in 2011:

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 ROMs".

https://lkml.org/lkml/2011/5/25/228


Even on servers, I noticed that HP (now HPE) began locking access to server UEFI updates soon after http://lkml.org/lkml/2013/11/11/653 was posted.


The PC platform as a whole is going through a severe case of "second system effect".


Even back in the 1990s, there was ACPI. ACPI 1.0 for example dates back to the end of 1996 (of course before then there was drafts): http://uefi.org/sites/default/files/resources/ACPI_1.pdf But of course ACPI took years to catch on, during which low cost PCs from for example eMachines was coming.


I seem to recall Torvalds having some less than kind words about ACPI.


I know. In fact, there is a reason I wonder what would have happened if Intel bought Compaq back in 1991 with Rod Canion and Jim Harris staying on.


Every desktop motherboard comes with a legacy bios, and virtually all of them come with a bios flashback USB port that can be used even without a CPU (it's used in cases where you fucked up the system completely, or you have a CPU which requires a newer bios).

Laptops are another story.


I think you can easily do some of the UEFI DoS attacks directly from Windows without executing an EFI binary.


And all of it just because they didn’t have a Windows 10 VM.

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.


> 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...


I usually check the hashes of all software I download. How do I check the hash if the vendor doesn't publish it, you might ask? Simple, calculate it and Google it. If you find what look like legitimate hits associating this file with this hash, call it good.

And it does work in this case - try googling both the published good and bad hash :)


In this case a distribution site which hosts both the hash and the file was hacked. This test is only good for "is the integrity of the download good" not for "is this created by the original developer". An authenticode or PGP signature is much better.


It is good if the compromise is not large-scale or is recent (e.g. only one of the mirrors was compromised, or the compromise is recent enough that search engines and such don't know much about the hacked version).


It helps that signing packages for Linux distributions costs $0, since they all use GPG. I actively avoid adding repositories that aren't signed with GPG keys for this reason, though it still doesn't protect me from compromised keypairs.


The attackers are saying they intended this more as a prank or warning, rather than something completely destructive.

It wipes the MBR, but no other data. The MBR isn't that hard to recover.


or ramsomware!


A classic Bootsector virus to go with the classic Windows shell...


A classic bootsector virus would infect any floppies that had been left in the machine when it booted.

Presumably you could do the same thing these days with any USB flash drives that had been left plugged in.


Audacity was also affected for a brief time, and the Audacity page about it (http://www.audacityteam.org/compromised-download-partner/) has much more information including the FossHub statement.

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.


A youtuber who usually does videos of classic DOS viruses made a video of this one in action.

https://www.youtube.com/watch?v=DD9CvHVU7B4


This comment (http://www.classicshell.net/forum/viewtopic.php?p=27961&sid=...) on the forum thread posted md5/sha1 checksums of clean & infected 4.3.0 installers (though it's not clear if those are only infected checksums).

   ClassicShellSetup_4_3_0_clean.exe
   MD5: e10881b65c27c6e09e5a33cd8bcd99c6
   SHA1: a6b06d07fe3b1a7204b1b62c67fbf3c602385364
   File size: 7220496 bytes

   ClassicShellSetup_4_3_0_infected.exe
   MD5: c67dff7c65792e6ea24aa748f34b9232
   SHA1: 438b6fa7d5a2c7ca49837f403bcbb73c14d46a3e
   File size: 7148732 bytes


Are the people over there sure that it's a good idea to rely on the broken[1] MD5 and the close-to-be-broken[2] SHA-1 for verifying checksums in the context of malicious actors? Though I guess the hashes and file sizes differ, so I guess this is just being pedantic.

[1] https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities

[2] https://sites.google.com/site/itstheshappening/


MD5 is broken in a sense that you can craft two different files with the same hash, but it's still hard to create a file with specific MD5 hash.

So it's still good for identifying files that aren't specifically crafted to have a malicious counterpart.


From this use case, where one person makes a file, and then an attacker forges another one with the same hash, MD5 was just recently broken and SHA-1 is far from it. Also, it's not immediately clear if a pair of broken hashes is also broken or not (depends on many things, and I probably don't even know half of them).

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.


It seems more reliable to check the developer signature in Properties on the EXE - the correct developer is "Ivaylo Beltchev". The infected download is unsigned and requires you to click through a warning.


Though annoyingly it's signed using sha1, not sha256.

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.


Someone have a copy of the infected version? I'd like to take a look.


FossHub was compromised and only downloads from there were affected, various other projects were also affected.


Apparently the hacked one wasn't signed. Users would have clicked through a (very prominent) warning to install it.


I get warnings every time I try to run something I downloaded, so I've just tuned them out. Unless this one was somehow completely different from those, I wouldn't have given it a second thought.


Unless SmartScreen complains, the order of dialogs and buttons on those dialogs is exactly the same for both signed and unsigned programs. They only differ in content/design elements. That's not what I'd call prominent.

There's nothing like HSTS for signed programs, so it can't be helped, though.


On Windows 10 you cannot install unsigned installers at all without disabling SmartScreen.


That's not true. Although the screen wide dialog thingy is a little tricky, you can still choose to continue. It doesn't even appear most of the time.


Yeah but loads of software isn't signed so the warning is fairly useless.


Those warnings are as useful as the certificate error ones you get when browsing the web. Most (normal) people see them as annoyances and they do not really protect anyone as they will just click "continue." Same with the UAC pop up that tells you that the app is not signed. Most of the apps I downloaded are not signed...


From the linked forum post:

>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.


MS just made all drivers required to be signed and I suspect the next step is to disallow downloads of executables that aren't signed. No, I don't mean smartscreen warnings, I mean a refusal to download entirely with exceptions being put in manually via a control panel item Grandma will be hesitant to mess with and via GPO for enterprise.

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.


It's not something that people pay attention to anyways...


Yeah, but many apps for Windows still aren't signed so many users are trained to just click through.


I watched the video in this thread. I would not consider that a prominent warning at all. UAC uses a near identical prompt and I need to click through it daily (average of 2-3 times an hour while doing development). It is not something I would have noticed.


Seriously, I've clicked through that on purpose many times with a lot of open-source projects, in development stuff, hell, I've gotten unsigned programs from companies!


I once got a virus from a well known company as a dev preview. Had to say it wasn't something i considered a fix. IT was not pleased..


So this appears to be a compromise of the download site, and probably could've been avoided with a hash verification, blah blah blah. Finger wag at developer.

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.


Piggy backing on ayuvar's comment, it would be better to sign your installer, and then have your front page/download page tell the user to be sure the installer is signed (show pictures, tell them what to look for, etc).


Per the developer at that forum thread:

"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.


I doubt it as well, and I completely agree with what you and others have said. While I rarely use Windows, it's unsurprising to see software from smaller development shops release software with no signature (or at least historically it's been unsurprising). So, this complacency sort of breeds the habit of simply clicking through and installing anyway. Heck, I even remember when installing certain drivers often required clicking through similar warnings since they occasionally weren't signed.

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 was just suggesting it would be easier to have people check for the displayed signature than get them to hash their download and compare it to something on the website.


Just to be clear, the original Classic Shell installer is signed. I agree they could make the point of having people check that.


End-User-Effort just doesn't work, sadly.

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.


Signing the installer would help detect tampering, except it seems like in this case the compromised installer was not signed and the usual one is.

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.


In theory that's what Windows SmartScreen is there to prevent.


Unfortunately every single one of those terrible "stop Windows 10 spying on you!!!" guides tells people to turn off SmartScreen along with UAC/Windows Firewall/Windows Defender.

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...


SmartScreen is functionally useless, though. All it provides is a UAC warning for unsigned code, the likes of which through a legitimate user has clicked an untold number of times for perfectly legitimate reasons.

Here's a video where the malicious file is executed. Nothing immediately seems amiss: https://youtu.be/DD9CvHVU7B4?t=1m43s


What you see in that video isn't SmartScreen, SmartScreen is disabled in that video.

Here is what SmartScreen actually looks like and actually does[0] 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).

[0] http://imgur.com/a/l5JzM


The issue is that due to the high costs of getting a certificate, a lot of legitimate software for Windows is still unsigned.

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.


Ah, yup. Good catch!


This is another reminder of how the security model of desktop OSes is pretty terrible. Every time you install software on Windows, you trust it with everything on your computer by giving it administrative rights.

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.


UWP apps don't have this problem. You can install from the store in the context of your user.

But everyone "hates" UWP apps[0] so....

[0] http://betanews.com/2016/07/27/windows-10-could-kill-steam-w...


I agree, in a way, but what is the point of root access on an OS X workstation? The "good stuff" -- bank accounts, personal data, etc. -- is inside that user account, even if it's not an admin user. And you can backdoor the user account to a point that the average user will never find it, making getting root less of a useful achievement.


Yeah, at this point I'd like a warning on first launch of an app that's not sandboxed (sandboxed apps can only access files that have been selected through a system "open" dialog). Although of course once Apple do that it'll launch cries of slippery slope across the community and it won't really help casual users who don't understand the security model...


OS X doesn't have this problem usually, as most apps don't require admin rights to install, you just copy them to /Applications

/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.


Yes, dragging the application there requires admin rights, but it doesn't grant those to the app itself.


What if the app had an suid binary?

Disclosure: I'm not a mac user, and never have been one long enough to mess around with /Applications.


It would run as your user. The files there aren't owned by root.


There still is not (AFAIK) much partitioning between apps on most desktop OSes. So even if a malicious app doesn't have admin rights, it still can run under your UID, which is almost as bad as it then has access to nearly everything you care about.

Obligatory xkcd: https://xkcd.com/1200/


Apps on OS X that have been installed through the App Store are sandboxed which is pretty close to the partitioning on iOS - for instance they can only access files the user has explicitly given access to (open dialog, double-clicking, drag and drop onto the app).

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.


UWP apps installed via the Windows Store have many of the same limitations (can only access own files, runs in a limited security context, etc).


And because that, I never allow to my web browser to remember my passwords.


The application can still get them, it doesn't matter whether they're in a file on your hard drive or typed manually.


Yeah, user account access is bad enough on its own.


Pretty much true. As these attackers stated on their own twitter "You ran it as admin, just be glad we didn't steal everything". All it takes is user access to dump all your stored passwords and run, which is what most attackers would do (there are even public tools they can deploy like iStealer that basically do this for them), from there they sell your accounts. From what I gather on their twitter these guys are pretty much doing it for the lulz.



The fix: http://www.classicshell.net/forum/viewtopic.php?f=12&t=6434&...

Close one for me: I was downloading WinDirStat when I came across that post.


Semi-unrelated: WinDirStat is amazing, but you might also look at WizTree for speed - it does its space analysis based just on reading the MFT, so it's quite fast.


I must have gotten very lucky, because I downloaded and installed installed Classic Shell on a fresh Windows 10 install yesterday afternoon and was not affected - the installer bore the right signature and my system is intact and boots fine. If I had tried a few hours later, I would probably be reinstalling Windows 10 for the second time in 2 days.


I hope the auto update wasn't affected. I just did this at work, no big warning screen. Now I'm paranoid to reboot..

Update: Looks like I wasn't affected. There was an official update (4.3.0) which was released on the 30th leading to unfortunate timing.


The thread on Classic Shell specifically notes that the auto update pulls from a different source that was not affected.


It also verifies signatures before it will execute the update, so even if that source were hacked it wouldn't have been affected.


Twitter account of the hackers: https://twitter.com/CultOfRazer


I'm not sure it's appropriate to give that kind of people unwarranted publicity.


What "kind of people"?

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.


Black hat hackers who bask in people calling them names in response to their mischievous adventures.

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.


Links on HN are rel="nofollow" so they're not going to get any google juice.


I don't think SEO is what pluma is concerned about


So what are they concerned about then? There's some moral wrong to watching crooks be crooks?


There's some moral wrong giving people exposure who are being obnoxious in order to get exposure.

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.


Don't think of it as publicity, think of it as threat intelligence.


Relevant tweets:

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.


Classic Windows. I miss the 90s.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: