Teracopy package hijacked? Is it really this easy to take control of a package?

[nothsa]

In PR #20548, it looks like the Teracopy install URL has been changed from the official one (https://www.codesector.com/files/teracopy.exe) to some BackBlaze B2 bucket (https://codesector.s3.us-west-000.backblazeb2.com/teracopy.exe). The SHA for the EXE currently matches the official one, but it could be changed at any point by whoever controls the bucket.

This feels like a major security risk, where anyone can submit a PR to change the install URL of a package, and any user that runs a winget upgrade on a package that was installed from the official install URL, could receive a malicious update. Am I missing something here?

[ItzLevvie]

https://www.codesector.com/files/teracopy.exe is a temporary redirect to https://codesector.s3.us-west-000.backblazeb2.com/teracopy.exe, so your concerns about but it could be changed at any point by whoever controls the bucket. shouldn't be a huge issue here as the only person that has control over that bucket right now is the CodeSector developers, and no one else is allowed. If a malicious person took over the bucket, the hash would likely change and then no one can install it until the hash is fixed in the package where it has to go through automatic and manual validation again as well as automated and manual virus checks, and then the database will be updated with the new changes.

If the publisher no longer uses https://codesector.s3.us-west-000.backblazeb2.com/teracopy.exe and moves to hosting their downloads on Google or Amazon, then that will definitely be an issue because the URLs won't work anymore and there's nothing for the website to redirect to. You'll simply just get 404 Not Found or 403 Forbidden. Though, all URLs in this repository are being scanned regularly by various scripts, and if a particular URL doesn't work or if the SHA256 hash does not match, we can easily fix it by looking for a new download link from the official website or official release distribution.

You're right that the redirect for the download URL shouldn't have been changed, since WinGet can handle redirects by itself, but I done this purely to reduce the amount of 301 URLs (as well as majority of the 302 URLs) where some 301 URLs were incorrectly flagged as 200 by cURL or Wget, but were actually 404 - i.e. mp3tag and some other packages, etc.

Same with 7-Zip, developers moved their downloads from the official website to GitHub. Recently, they deleted the GitHub account and moved their installers back to the official website. SHA256 of those installers never changed, I'm guessing the developers did this to reduce the amount of overhead or bandwidth on 7-Zip's servers, and allow other people to download it faster from GitHub's CDN.

Also, not every single package in this repository uses official links. IrfanView is one of them because it doesn't allow hotlinking downloads, so we have to use download links from BetaNews or somewhere else.

A common comment I have seen a few months ago from someone here has said something along these lines: "Please don't use i.e. TechSpot because this website has adware and may have tampered the software." but we got no choice other than to use URLs from various mirrors due to hotlinking. We also check the hashes to make sure it matches the official sources. If this worries you, keep an eye on when the Microsoft Store source becomes the default source (instead of the community repository where you'll have to manually opt-in to use it in the future) for WinGet that way you'll know what you're downloading.

I don't see where security risks would be an issue here because every installer goes through Dynamic Analysis (Virus Scan) in the Pipelines' VMs, and if there's a PUA or malware in the installer, it's immediately flagged by the pipelines. The PR is also manually validated by Moderators, in either VMs, or Bare Metal - so installers are always double checked to make sure that it isn't a malicious package intended to steal people's passwords or monitor what they're typing on their keyboard:

Even if the pipelines cannot catch the malware issue, depending on the antivirus software someone has, all installers from WinGet are downloaded to %TEMP%\WinGet, except for .appx(bundle) and .msix(bundle), where your antivirus software will probably scan it before it's executed to install it onto your PC.

[nothsa]

Thanks for the detailed response! I'm still new to winget and didn't realize that there was going to be a logical separation between the MS store and community repos, and that the MS Store would be the default with community being opt-in. That alleviates most of my concerns for layman users.

I would still love to see an indication/warning that the installer source has changed if you're upgrading an already-installed package (at minimum when there's domain changes), and show the URL of the new installer. If (as you indicated) you're manually checking hashes against the application's official source then this is less of an issue, but that seems like manual validation would become unmanageable once there are thousands of apps in the community repo (though maybe I'm wrong about that 🙂).

As a side note regarding automated scanners/antivirus, as great as they are, we shouldn't be relying on them completely to catch anything malicious. It's easy to think of a number of malicious actions that automated systems wouldn't catch. E.g. a Teracopy where every copy/move action is redirected to the delete action. Or an Irfanview that adds a watermark to every image you save and deletes the original. Again, if the manual validation of the hashes from the official sources continues then this isn't a problem, I'm just concerned what would happen if/when those manual hash validations stop.

[ItzLevvie]

That alleviates most of my concerns for layman users.

That's great to hear :)

Since unpackaged Win32 apps are now allowed in the Microsoft Store, you can speed this process up until the msstore possibly becomes the default source by running winget source remove --name msstore now.

Over time, more and more apps will be available in the Microsoft Store.

There will also be verified publishers (i.e. EarTrumpet - as the developer complained that their package was tampered with and allowed people to install development builds rather than production builds) that will manage their applications in this repository, that way contributors and moderators are not allowed to make any changes to those packages.

I would still love to see an indication/warning that the installer source has changed if you're upgrading an already-installed package (at minimum when there's domain changes), and show the URL of the new installer.

You could perhaps file a new feature at https://github.com/microsoft/winget-cli/issues/new?assignees=&labels=Issue-Feature&template=Feature_Request.yml requesting this.

I'm still new to winget [...]
If (as you indicated) you're manually checking hashes against the application's official source then this is less of an issue, but that seems like manual validation would become unmanageable once there are thousands of apps in the community repo (though maybe I'm wrong about that 🙂).
I'm just concerned what would happen if/when those manual hash validations stop.

If you've used Chocolately or Scoop as a package manager on Windows, the security of packages or installers should be more or less the same.

You'll never be able to install an application if the hash changes, and for WinGet, you'll never be able to install an application with an invalid hash with administrator privileges, therefore, the user must accept UAC if the installer wants to make changes to your PC if you're using the --force parameter.

When it comes to download URLs, there's the @wingetbot which is an automated bot specifically made for this repository which checks all of the packages' download URLs and installer hashes in the repository and automatically files an issue on the issue tracker if the hash doesn't match or if the download URL no longer works.

In case the bot doesn't properly check the download URLs or installer hashes, I and another contributor both have a scripts for it made to sort of mimic what @wingetbot does. I recently made a debug script with aria2 and cURL to verify all installer hashes in this repository, and managed to update less than 50+ apps with incorrect hashes - to put it in comparison: there's currently more than 2600+ apps in this repository with 11,000+ URLs.

Most of these invalid hashes come from download URLs that aren't versioned, so installer hashes like the ActivePerl applications may sometimes change its installer hash multiple times per day, or every single day.

Your concern for this would have been completely valid if all PRs people made were automatically merged after automated validation, which was the case before, but that isn't the case now with manual review from moderators and administrators.

As a side note regarding automated scanners/antivirus, as great as they are, we shouldn't be relying on them completely to catch anything malicious.

That's obviously true, but aside from Microsoft's own anti-virus software (Microsoft Defender), and other third-party anti-virus software currently used in the Azure Pipelines for PR validation, there's also URL ratings, Microsoft Defender SmartScreen, and possibly more that I'm missing here.

Microsoft is most likely using private APIs for all of this (with perhaps help from other companies, i.e. Google's malicious URLs database, but that's hard to tell because the pipelines are closed source), especially when there's billions of users using Windows, the virus definitions and security gets better over time.

As a former moderator for Chocolately (who was under a different username/account back then), we only made sure to see if the URLs were coming from official sources (+ include SHA256 in the package so if the installer changes the app won't install until you file a complaint and let the maintainer know) and to validate installers against VirusTotal. That was all.

There wasn't any sort of manual review to check if the app deletes system or user files when you move or copy files using a particular application. This is a good point to make, but is complex with how applications are made today because there's just way too many scenarios to consider with how much functionality an application has. This may have changed today with Chocolately, but I wouldn't really be surprised if it hasn't.

With WinGet, once a hash in a package changes, most people will not be able to install the application unless they explicitly give the --force command which most people will most likely not run if they want to prevent malware from getting into their PCs or are security cautious, so the chances of that happening is quite slim.

i.e. if CCleaner got compromised again, doing winget upgrade --all will not upgrade you to that version because the chances are that the hash already changed to implement backdoors or malware by an attacker. We would probably be notified about the security compromise in various news articles or in the issue tracker and then probably take that package down temporarily.

I work at Microsoft as a contractor - blue badge as an intern and then stepped down to an orange badge as a contractor - you'll be surprised how easy it is to update and patch more than 200K+ employees' PCs. As soon as an emergency update (i.e. an update that's needed to solve security vulnerabilities that's being exploited in the wild) article goes up on The Verge or other news sources, it's an immediate scheduled Windows Update within an hour or so of that article going up, at least in my Europe forest (which may be different in Redmond and other forests).

I always say to people to install applications you trust (perhaps popular apps or apps made by big publishers) as there's a lot of community apps here, and one of them may or may not delete files from your OS if it's an app that's not widely used by a lot of people or is too new.

So, if there's a website or an installer that's compromised in WinGet, please feel free to make an issue about it. Just like what a user did a few days ago, i.e. #32741 which will inform us to fix the package.

[vedantmgoyal9]

I work at Microsoft as a contractor - blue badge as an intern and then stepped down to an orange badge as a contractor

Can you please explain more about this?

Microsoft is most likely using private APIs for all of this (with perhaps help from other companies, i.e. Google's malicious URLs database, but that's hard to tell because the pipelines are closed source), especially when there's billions of users using Windows, the virus definitions and security gets better over time.

cc @jedieaston, is this the reason that the pipelines and @wingetbot aren't open-sourced😁?

[ItzLevvie]

Can you please explain more about this?

Big technology companies have several different badge colors to differentiate employment types like full-time employees, part-time employees, temporary employees, university internships/apprenticeships, high-school internships, etc.

cc @jedieaston, is this the reason that the pipelines and @wingetbot aren't open-sourced😁?

Private Services & APIs is one of them: #13643 (reply in thread).

Validation Pipelines and @wingetbot will most likely be open-sourced in the future according to #34421 (comment) but it won't be the entire source code. It'll be similar to Microsoft Edge where half of the source code is closed source.

[cjwijtmans]

I think a hash alone is not sufficient for security. Perhaps a parity file would be better.