Install-ChocolateyZipPackage might contribute to VirusTotal false positive

[laura-rodriguez]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my problem.
• I have verified this is not an issue for a specific package.
• I have verified this issue is not security related.
• I confirm I am using official, and not unofficial, or modified, Chocolatey products.

What You Are Seeing?

I'm currently in the process of submitting a new package, which is now under moderator review.
VirusTotal reports that 1 out of 60 scanners (MaxSecure) throws a warning of malicious file "Trojan.Malware.300983.susgen", which is a false positive as we can ensure the integrity of the package.

I noticed other open-source projects also struggled with scanners' false positives, especially the MaxSecure scanner:
getsops/sops#1331
pypa/setuptools#4063
https://www.reddit.com/r/techsupport/comments/o52rq3/trojanmalware300983susgen/

And I also understand Choco doesn't handle how anti-virus scanners work.

Having said this, are there any enhancements in the ChocoInstall script we could do to avoid false positives? It seems the usage of Install-ChocolateyZipPackage contributes to the following warning:
"Matches rule Password Protected Compressed File Extraction Via 7Zip by Nasreddine Bencherchali (Nextron Systems) at Sigma Integrated Rule Set (GitHub)
Detects usage of 7zip utilities (7z.exe, 7za.exe and 7zr.exe) to extract password protected zip files."

Scanning zip files separately and the NuGet package don't throw any flags.

Thanks in advance!

What is Expected?

Avoid false positives that damage packages reputation.

How Did You Get This To Happen?

I submitted a brand new package and this is the scan result: https://community.chocolatey.org/packages/okta-aws-cli/1.2.2#virus

System Details

• Operating System:
• Windows PowerShell version:
• Chocolatey CLI Version:
• Chocolatey Licensed Extension version:
• Chocolatey License type:
• Terminal/Emulator:

Installed Packages

N/A

Output Log

Crowdsourced Sigma Rules
CRITICAL 0
HIGH 0
MEDIUM 1
LOW 1

Matches rule Password Protected Compressed File Extraction Via 7Zip by Nasreddine Bencherchali (Nextron Systems) at Sigma Integrated Rule Set (GitHub)
Detects usage of 7zip utilities (7z.exe, 7za.exe and 7zr.exe) to extract password protected zip files.

Matches rule Creation of an Executable by an Executable by frack113 at Sigma Integrated Rule Set (GitHub)
Detects the creation of an executable by another executable

Additional Context

No response

[pauby]

I'm unclear on what the issue is.

The files that are in your package are uploaded directly to VirusTotal. Install-ChocolateyZipPackage hasn't done anything to the Zip files that are in the package (or their hashes would have changed) so I'm unsure how this comes in to play to ensure that your files are receiving AV detections.

And I also understand Choco doesn't handle how anti-virus scanners work.

I'm unclear what you mean here. Can you elaborate?

[laura-rodriguez]

Hi @pauby,

I'm new to the process of uploading packages into Chocolatey, so I apologize if I wasn't clear enough. This issue is mostly a question about what things a maintainer can do to avoid false positives.

As I mentioned, I've submitted a package, a zip file that contains a .exe file, and VirusTotal is reporting a warning for a potential vulnerability (trojan.Malware.300983.susgen).
In order to analyze and mitigate the warning, I went ahead and uploaded the zip files and NuGet package to VirusTotal, and no vulnerabilities were detected, as you can see here:

• VirusTotal Report Windows x64
• VirusTotal Report Windows x86
• VirusTotal Report Choco NuGet pkg

As no vulns were detected, I dug deeper into the VirusTotal report provided in the Chocolatey package dashboard, and I noticed this particular one:

Matches rule Password Protected Compressed File Extraction Via 7Zip by Nasreddine Bencherchali (Nextron Systems) at Sigma Integrated Rule Set (GitHub)
Detects usage of 7zip utilities (7z.exe, 7za.exe and 7zr.exe) to extract password protected zip files.

Considering all files don't throw any vulns independently, is it possible that this MEDIUM vuln is caused by Install-ChocolateyZipPackage and the way 7Zip utilities are being used underline? Is there any recommendation to mitigate false positives that can be done on the Choco scripts side?

[pauby]

Thanks for clarifying. I converted this to a discussion, as I don't believe it is an issue.

I'm new to the process of uploading packages into Chocolatey, so I apologize if I wasn't clear enough. This issue is mostly a question about what things a maintainer can do to avoid false positives.

I'm going to try to go through your comments and explain each point, and I apologise in advance if I'm explaining things you already know, but I just want to make sure we are on the same page.

As I mentioned, I've submitted a package, a zip file that contains a .exe file, and VirusTotal is reporting a warning for a potential vulnerability (trojan.Malware.300983.susgen).

There are a few things here. The Chocolatey package page that you mentioned in your first comment, shows the hashes of the files that are downloaded by the package upon install (not that they are the short versions of the hashes on this page).

The Chocolatey package install script, chocolateyInstall.ps1 also has the same hashes:

And the files downloaded from GitHub (that are also in the chocolateyInstall.ps1 have the same hashes:

https://github.com/okta/okta-aws-cli/releases/download/v1.2.2/okta-aws-cli_1.2.2_windows_386.zip:

https://github.com/okta/okta-aws-cli/releases/download/v1.2.2/okta-aws-cli_1.2.2_windows_amd64.zip:

So what we can say here is: that the files downloaded from your GitHub releases during the installation of the package, by Package Scanner, and by me, have the same hashes. So they are identical files.

If we look at the files that were uploaded to VirusTotal by Package Scanner, we can see they have the same hashes too.

There is an AV detection in the x64 version of the ZIP file, but that isn't something that Chocolatey CLI has caused. As I've shown above, the file at each stage has the same hash so hasn't changed. Therefore, the file on your GitHub releases has an AV detection, because of something in the ZIP file. That would be something you would need to investigate and resolve.

In order to analyze and mitigate the warning, I went ahead and uploaded the zip files and NuGet package to VirusTotal, and no vulnerabilities were detected, as you can see here:

VirusTotal Report Windows x64

That is for the arm64 version, which has not been submitted to the Chocolatey Community Repository. I think you meant to provide the amd64 version. This may be where all of the confusion is. The arm64 has no AV detections but the amd64 one we in the package does.

VirusTotal Report Windows x86

This is the same file uploaded to the Chocolatey Community Repository and has the same number of AV detections, so there isn't anything to comment here.

VirusTotal Report Choco NuGet pkg

That package doesn't contain any of the Okta ZIP files that were submitted to the Chocolatey Community Repository, as it is only 3.35KB. So there is nothing to detect, or comment on, here.

From the Chocolatey Community Repository package page:

okta-aws-cli_1.2.2_windows_386.zip (dfd418999cf1)

okta-aws-cli_1.2.2_windows_amd64.zip (5d8865b3df88):

As no vulns were detected, I dug deeper into the VirusTotal report provided in the Chocolatey package dashboard, and I noticed this particular one:

Matches rule Password Protected Compressed File Extraction Via 7Zip by Nasreddine Bencherchali (Nextron Systems) at Sigma Integrated Rule Set (GitHub) Detects usage of 7zip utilities (7z.exe, 7za.exe and 7zr.exe) to extract password protected zip files.

I found this here:

That is a VirusTotal 'thing', so you would need to contact them about it. Once files are uploaded into VirusTotal, we have no control over what rules / AV engines they apply. But just to be clear, this is nothing that Package Scanner has done to the file, and we know that because the hashes of the files hosted on your GitHub page match the hashes of the files in VirusTotal. If they had been altered, those hashes would not match.

Considering all files don't throw any vulns independently, is it possible that this MEDIUM vuln is caused by Install-ChocolateyZipPackage and the way 7Zip utilities are being used underline?

Simple answer, no.

Here is what Package Scanner does:

1. When Package Scanner is given the job of 'scanning' your package it downloads it from the Chocolatey Community Repository (in the same way anybody does - it doesn't get special treatment as we want to ensure that it matches what the end-user would do).
2. It looks at the package scripts and decides on what to do. In the case of this package, it then uploaded them to VirusTotal.
3. Once VirusTotal has scanned them, it grabs the detection results (at the time those were 1 out of 63 for both the amd64 and i386 files - see below for more about this) and makes them visible on the package page.

It doesn't do anything more than that.

Install-ChocolateyZipPackage or 7Zip utilities don't alter the ZIP files that are in the package, and we know that because the hashes of the files in your GitHub release match those in VirusTotal. So they are the same files.

Is there any recommendation to mitigate false positives that can be done on the Choco scripts side?

The AV detections are done by VirusTotal. We don't do the detection and therefore cannot influence any results. What you give us, we give to VirusTotal.

If your package has any AV detections, then you need to look at what is being detected and on what files and work to mitigate the issue. VirusTotal gives you a lot of information, as you can see, whereas the Chocolatey Community Repository package page only gives you the AV detection results, simply 1 / 63 in this case, and a link to the VirusTotal report.

I hope the above demonstrates that your amd64 ZIP file is being detected as having an AV detection so you would need to investigate and fix that.

A couple of things worth mentioning:

1. It's wise to upload your files to VirusTotal before submitting your package to the Chocolatey Community Repository. Part of what Package Scanner does is it checks to see whether VirusTotal already knows about the files in the package. If it does, we simply grab the AV detection results and move forward. If it doesn't, we submit the files and then keep checking back for the AV detection results. Only when those results are received, do we then move forward. To speed up the process, upload the files beforehand, so Package Scanner only has to grab the AV detection results.
2. When the package was first submitted, the i386 ZIP file had 1 AV detection. This has since changed in VirusTotal to be 0. I have made a request to have Package Scanner update those results with the new AV detections from VirusTotal and that has just completed. Note that the amd64 still has 1 AV detection. The reason that the number of AV detections can change is that the definitions of the scanner that made the detection. Just like a false positive on your computer.
   
3. With 63 AV scanners, some of them very obscure, you're going to get AV false positives. It happens regularly.
4. We consider < 4 AV detections a false positive and while your package would be held for a moderator to look at it, they would not hold the package back from being approved on that basis.

This was a long post, but I hope it clarifies that this issue is not one that Chocolatey can solve for you. This is an issue in your Okta package that needs to be resolved by you. However, should you consider it a false positive, we would not stop it being approved with only 1 AV detection.

[laura-rodriguez]

@pauby, thank you so much for your time and such a detailed response. This is super helpful and narrows down the root causes for the reported vulnerability facilitating a more targeted approach to resolve it.