Addressing malware

All suggestions about TPFC should be posted here. Discussions about changes to TPFC will also be carried out here.
Post Reply
Message
Author
User avatar
webfork
Posts: 10818
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Addressing malware

#1 Post by webfork »

As was discussed recently, the very popular CCleaner recently got infiltrated by malware. This isn't the first time this has come up, but it may be one of the most popular programs this has affected, harming the widest group of people. I've begun to wonder if the site doesn't need to take some additional steps for our visitors.

The problem

It doesn't matter that this is still exceedingly rare and that Windows is much better than many other platforms for freeware. It also doesn't matter that for years I didn't even run anti-virus on my machine while still testing hundreds of programs. Malware developers are increasingly targeting freeware, that's alienating users and tarnishing the efforts of a lot of good people who give away their work for free. I have had far too many conversations about this with people over the past two years.

The solution

I'd like to suggest addressing that on the website in some way. I've hesitated on this in the past because it seemed that putting a warning at the top of the site was just another way to make people think that freeware was unsafe, but now I'm starting to wonder if it's worse to not clearly address it. We might do that through recommending use of VirusTotal, anti-virus, and tested, reliable backups tools.

Suggestions?

I'm still thinking about what that might look like but I wanted to post something here and see if anyone had ideas about how to approach that.
Last edited by webfork on Fri Sep 22, 2017 2:17 pm, edited 2 times in total.
Reason: (improved wording)

Specular
Posts: 443
Joined: Sun Feb 16, 2014 10:54 pm

Re: Addressing malware

#2 Post by Specular »

I think personally if I were looking at an entry or browsing I'd appreciate a program's entry bumped to the front page and note in the entry's description regarding known malware-affected versions of software with a link to a level-headed article with more info, at the date of the infection. Given a period after the malware has been removed it's probably less necessary to remain in the description and could just be left in the form of an entry comment.

That would be mostly only useful for new visits/downloaders and such an updated message mightn't reach existing users but it's better than nothing. News of high profile programs infected with malware will likely reach users' attention other ways via other channels like articles and internet word of mouth.

In CCleaner's case there was really no way a user could have predicted this. It was signed using their own keys IIRC and pushed as a regular update. The only takeaway as a user would be to keep an eye out for news about updates of programs you use and if you're cautious to disable auto-updates (which for portable programs is kind of the normal state anyway, at least in my experience).

User avatar
joby_toss
Posts: 2970
Joined: Sat Feb 09, 2008 9:57 am
Location: Romania
Contact:

Re: Addressing malware

#3 Post by joby_toss »

Ideally, for me, every database entry would have another field (named "threat level" or whatever) based on VirusTotal analysis.

For CCleaner v5.33, here are the VT results for the entire archive and for the 32 bit executable:
https://www.virustotal.com/en/file/6f78 ... 506119965/

https://www.virustotal.com/en/file/e710 ... 506111834/

As you can see, they have over half worrying results and that would translate into a RED label (or 5 red exclamation marks or whatever) in the threat field. A green label would mean safe (0 VT warnings), a yellow one (1-5 VT warnings) - be careful, read more etc...

However, the problem is that not all packages can be scanned on VT, or the db updater may not have the time to do the scans, etc. In that case the label should be some indicator that the program's threat lvl has not been established yet (grey color?, pink?).
Also, a warning should be put in place stating that a VT score of 0 doesn't equal an absolutely safe package!

Or something along those lines...

P.S. of course, one may argue what's the point of listing a package with a RED label, instead of the previous safe version, but I, for one, would prefer to know the current version's state of affairs, 'cause i can always find the previous version if i really need it.

User avatar
SYSTEM
Posts: 2041
Joined: Sat Jul 31, 2010 1:19 am
Location: Helsinki, Finland

Re: Addressing malware

#4 Post by SYSTEM »

joby_toss wrote:Ideally, for me, every database entry would have another field (named "threat level" or whatever) based on VirusTotal analysis.

For CCleaner v5.33, here are the VT results for the entire archive and for the 32 bit executable:
https://www.virustotal.com/en/file/6f78 ... 506119965/

https://www.virustotal.com/en/file/e710 ... 506111834/

As you can see, they have over half worrying results and that would translate into a RED label (or 5 red exclamation marks or whatever) in the threat field. A green label would mean safe (0 VT warnings), a yellow one (1-5 VT warnings) - be careful, read more etc...
It would still be only of limited help. AFAIK, antivirus programs didn't detect CCleaner 5.33 as malicious at the time it was released.
My YouTube channel | Release date of my 13th playlist: August 24, 2020

Specular
Posts: 443
Joined: Sun Feb 16, 2014 10:54 pm

Re: Addressing malware

#5 Post by Specular »

SYSTEM wrote:It would still be only of limited help. AFAIK, antivirus programs didn't detect CCleaner 5.33 as malicious at the time it was released.
AVs aren't a perfect way of telling if a program contains malicious code, yeah. There's also the issue of false positives for even harmless software.

A dev wrote a blog post on how they could bypass AV detection rather simply (0/56 on VirtusTotal) last year which was useful to at least see that such scans aren't necessary a trustworthy metric. That said I still check archives of programs against it from time to time since if you take into account false positives and the information listed per AV you can make up your own mind about what it reports, along with any user reports I might read online. It does have its uses, though I'm not sure the score alone is something I'd rely on unless AVs have been updated to find specific, known malware (as happened later with that CCleaner version).

User avatar
SYSTEM
Posts: 2041
Joined: Sat Jul 31, 2010 1:19 am
Location: Helsinki, Finland

Re: Addressing malware

#6 Post by SYSTEM »

Specular wrote:A dev wrote a blog post on how they could bypass AV detection rather simply (0/56 on VirtusTotal) last year which was useful to at least see that such scans aren't necessary a trustworthy metric.
:shock:

I would never have expected that such a simple shellcode obfuscation technique would fly past AVs. Not in a million years. Just what on Earth are AV vendors doing?
My YouTube channel | Release date of my 13th playlist: August 24, 2020

User avatar
Midas
Posts: 6705
Joined: Mon Dec 07, 2009 7:09 am
Location: Sol3

Re: Addressing malware

#7 Post by Midas »

I would suggest publishing hashes (or possibly auto-hashing) as the quickest and simplest solution -- BTW, Virustotal links are based on a SHA-256 hash.

Certificate checking would be the way for taking that further but I'm afraid there's nothing simple about it.

bitcoin
Posts: 285
Joined: Sun Dec 31, 2017 6:32 pm

Re: Addressing malware

#8 Post by bitcoin »

could recommend the users install VT Hash Checker from Boredomsoft and have their download managers use it as the virus check program

User avatar
JohnTHaller
Posts: 714
Joined: Wed Feb 10, 2010 4:44 pm
Location: New York, NY
Contact:

Re: Addressing malware

#9 Post by JohnTHaller »

If you did a VirusTotal scan on each app update to ensure it was clean and published the associated hashes, end users could check hashes themselves to be sure. We do something similar on PortableApps.com. Every release is checked on VirusTotal, MetaDefender, and/or in-house with 2-4 major antivirus engines before being posted. We also scan the publisher files that our live installers download and hash them. If the hashes don't match, the installer will refuse to use it. If the example mentioned above occurred again and CCleaner was infected on the publisher's server, our ccPortable live installer would refuse to install it. Our platform's database includes the hashes of all files it downloads and will refuse to install any that don't match as well so users don't have to manually verify hashes from our website.
PortableApps.com - The open standard for portable software | Support Net Neutrality

User avatar
webfork
Posts: 10818
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: Addressing malware

#10 Post by webfork »

midas wrote:I would suggest publishing hashes
JohnTHaller wrote:If you did a VirusTotal scan on each app update to ensure it was clean and published the associated hashes, end users could check hashes themselves to be sure.
First, I actually suggested this once upon a time but the logistics of actually doing that are probably beyond the capacity of a volunteer-based website. A few issues include:
  • Who does it? Is it required for creating a new entry or for updates?
  • What about the many 100s of older entries?
  • If it's on some entries and not others, are the ones without a hash "unsafe"? What do we expect a user to do if the hashes don't match?
Second, thanks to Smaragdus' careful analysis, we know that many publishers update their programs without any notice nor version number change. This phenomenon is particularly frustrating as of course even a single byte difference results in a unique hash result. As a result, unless we distribute the executables ourselves (as PortableApps does) we can't hope to maintain reliable control over that. Since the bandwidth necessary for that is well above our ability to pay for, that's not currently an option.

At this stage, the only thing that sense to me based on our available resources is what Joby suggested: to have a button adjacent to each "download" button with a document on how to stay safe. VirusTotal supports website checks (e.g. https://www.virustotal.com/#/url/183939 ... /detection) but I don't think it supports direct linking e.g. virustotal.com/siteyouwanttocheck.net. We can additionally suggest people manually check their downloads with some notes on difference between a 1/56 rating (false positives) vs. a 16/56 rating (potential threat).

Anyway, I can draft something up on that and get that posted in the coming weeks if that sounds like a good idea.

bitcoin
Posts: 285
Joined: Sun Dec 31, 2017 6:32 pm

Re: Addressing malware

#11 Post by bitcoin »

webfork wrote: Thu Jan 04, 2018 2:16 pm
midas wrote:I would suggest publishing hashes
JohnTHaller wrote:If you did a VirusTotal scan on each app update to ensure it was clean and published the associated hashes, end users could check hashes themselves to be sure.
First, I actually suggested this once upon a time but the logistics of actually doing that are probably beyond the capacity of a volunteer-based website. A few issues include:....
that VT Hash Checker program does most of the work, including opening the URL to the VT results page. If the file isnt in the database yet, it will upload it for you and usually the scan will be finished in 2-3 minutes.

new addition to each program's page could be something like:

"VT Results: 0 of 60"

and then hover to see the VT link or click to open the VT page

only problem is some entries have 32 and 64 bit versions so is it worth it if you have to do that twice per program? and of course, lke you mentioned, are they getting the same file?

User avatar
webfork
Posts: 10818
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: Addressing malware

#12 Post by webfork »

I'm not sure I really solved the original issue discussed here, but I tried to put together a possible way to secure freeware.

User avatar
Midas
Posts: 6705
Joined: Mon Dec 07, 2009 7:09 am
Location: Sol3

Re: Addressing malware

#13 Post by Midas »

Great job. 8)

On related note, I can thank one of your posts -- the one about your SigCheck method (viewtopic.php?p=100019#p100019) -- for totally solving the obstacles I had previously noted here (see above viewtopic.php?p=87987#p87987).

User avatar
webfork
Posts: 10818
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: Addressing malware

#14 Post by webfork »

Midas wrote: Sat Mar 06, 2021 2:17 pm Great job. 8)

On related note, I can thank one of your posts -- the one about your SigCheck method (viewtopic.php?p=100019#p100019) -- for totally solving the obstacles I had previously noted here (see above viewtopic.php?p=87987#p87987).
Thanks -- these things are slow going but we're gradually making progress :)

Post Reply