wsl-ssh-pageant
wsl-ssh-pageant copied to clipboard
benpye
Windows Defender (and other AV) detects wsl-ssh-pageant-386-gui.exe as malware (false detections)
When downloading the latest release 20200408.1 of wsl-ssh-pageant, Windows Defender triggered an alert and quarantined wsl-ssh-pageant-386-gui.exe as malware.
The alert box includes the following details:
Trojan:Win32/Wacatac.C!ml
Alert level: Severe
Status: Active
Date: 4/18/2020 12:08 PM
Catagory: Trojan
Details: This program is dangerous and executes commands from an attacked
Affected items:
file: c:\Users\user\Downloads\wsl-ssh-pageant.386-gui.exe
Amusing, wonder what I've done to hit that false positive. VirusTotal shows a few detections but most software is reporting it as clean.
https://www.virustotal.com/gui/file/286435447f00181f4157dfc52dc7bf088ecfc952d61e8c8e2eee8fd0490d2082/detection
I've submitted this for additional analysis, hopefully we can get the false positive on Defender cleared. I will update this issue when I get any updates.
Note: as of last night, Windows Defender added wsl-ssh-pageant-386.exe to the malware list as well with the same Trojan detected.
I have seen other go installers with the same trojan detected by defender :-(
Hey - Thanks for letting me know @taxilian . I'm still working on getting this resolved. Sorry all!
This should be resolved if you update your malware definitions. I'll leave this issue open for a few days in case anyone still has trouble.
Still running into this with the latest malware definitions. It does not like wsl-ssh-pageant-amd64.exe but does like wsl-ssh-pageant-amd64-gui.exe.
McAfee is also doing this. It flashed up what kind of virus it believed it was, but now I can't get into a detailed report to see what it was. Windows 10 does not like the fact that the executable is not signed by anyone it recognises.
Problem still exists on Windows 10 with windows defender.
| App: | wsl-ssh-pageant-amd64-gui.exe |
|---|---|
| Herausgeber: | Unbekannter Herausgeber |
I'll take another look but if the solution is to pay for a code signing cert that's a pain.
Now being flagged as Trojan:Win32/Zpevdo.B by Microsoft Defender (for wsl-ssh-pageant-amd64.exe).
VT suggests a number of FP variants across vendors: https://www.virustotal.com/gui/file/d2979bed31d7fe09fbd0186a45ae029e1311eb44cc432cb88d232fd3a4f4c1e0/detection
I have the same problem that @IoInsecure for wsl-ssh-pageant-amd64.exe executable since today.
But when I compile the execute myself, VirusTotal claims its safe: https://www.virustotal.com/gui/file/0756c49bfaef190fdf85034b0fbc3a3623ee18b325f6e5759c8d515881fc14ce/detection
Ack - I will follow up again. I'm not sure there is going to be a good solution to this aside from code signing, which isn't really something I want to figure out.
Code Signing Help
It's the purchase of the code signing certificate (and installing it) that is the biggest pain point. But that's really it.
The Hard Part
The signing certificate people will have to verify that you exist (e.g. as an individual or as a organization), which might involve them calling you and checking identification. Takes about a week. If you run into roadblocks (e.g. business not registered in business directories), you could do something like purchase a DUNS Number to get yourself listed in a business directory that the code signing authority can use to verify the realness of your business. But first, try to purchase the certificate and then they will tell you whether or not you have to jump through additonal unexpected hoops. Anyway, getting yourself through jumping all the hoops is a royal pain at first but then you've got a certificate that you can use to sign unlimited executables you build for a time period. But it's often a once-in-lifetime hoop jump for any business, at least. If you're registering as an individual instead, then things are different (since no organization validation is needed), the process is different and simply involves supplying appropriate government identification, etc.
The Easy Part
Then the pain point disappears. Afterwards, it's easy!! After that pain..... the signing certificate is as easy as managing an SSH key in my experience. Quite easy to automate with a single signtool command under Windows.
Added to your extra commands in your Visual Studio post-build commands, or Makefile or whatever you use to compile Windows executables.
signtool.exe sign /a YourExecutable.exe
I also recommend cryptographic timestamping too, using your code signing authority's time server.
signtool.exe sign /a YourExecutable.exe
signtool.exe timestamp /t http://timestamp.comodoca.com/authenticode YourExecutable.exe
Buy From Sectigo or Digicert
One of the most popular certificate providers that is not too expensive is Sectigo, formerly Comodo. They're the 800 pound gorilla of Windows code signing certificates these days. Google "Sectigo code signing certificates". You could go through a reseller for even cheaper, but going to the Real McCoy (https://sectigo.com/ssl-certificates-tls/code-signing) is safer and bypasses the middlemen (some are good, some are scammers). Though you pay twice as much.
Now if you are tight on money and want to go through a reseller, one popular/trusted one is Sectigo Store which is much cheaper (https://sectigostore.com/code-signing/sectigo-code-signing-certificate). About $80/year. But support can be worse and regenerating/changing certificate later can be a hassle (email address change, name change, etc). Those are much easier with direct non-resellers. I went this route as I don't expect to need to change/modify the certificate.
If you want more luxuriously powerful signing certificates, you can use Digicert, and go Extended Validation. But that's overkill for ordinary userspace applications such as this utility, unless you're needing to sign kernel drivers...
If you're nervous, try buying a 1-year to begin with -- just to get the process started (since buying a 3-year right after a 1-year is much easier). Jump through the hoops they tell you to do (to get yourself verified as a real person or a real business). A week or two later, there's a 15-minute install instructions, and you're ready to go nuts on signtool.exe for up to 3 years -- whatever length you purchased.
(just protect the key like a valuable password/passport/bankaccount/etc -- you don't want hackers to gain a copy of it and sign their malware with your reputation!)
Just out of curiosity, could this be Defender identifying a Go library that is included that may have an exploit or vulnerability in it? Could library versions be shuffled to see if it changes the outcome?
I suppose that is possible, though looking through the dependencies I don't notice anything obvious.
It does appear that anti-malware software on Windows has a recurring issue with golang binaries:
https://golang.org/doc/faq#virus https://github.com/junegunn/fzf/issues/2002 https://groups.google.com/g/golang-nuts/c/Au1FbtTZzbk
The only uncommon dependency we have is https://github.com/apenwarr/fixconsole - we could see if a build without it triggers any detections. Reviewing the code I don't see anything suspicious but I guess it's possible there is some pattern that is throwing these false positives.
Also hitting this. Unfortunately, blindly allowing any binary to pass through Defender isn't really an option as it defeats the purpose of Defender.
I am also hitting this for wsl-ssh-pageant-amd64.exe and wsl-ssh-pageant-amd64-gui.exe using the latest release 20201121.2
The only uncommon dependency we have is https://github.com/apenwarr/fixconsole - we could see if a build without it triggers any detections. Reviewing the code I don't see anything suspicious but I guess it's possible there is some pattern that is throwing these false positives.
I wouldn't bother with chasing that fixconsole dependency. My project doesn't use that dependency but is triggering the same windows defender detection (zpevdo.b) as well as numerous VirusTotal vendors detecting something too. More information on the virustotal analysis in the issue linked just above this comment.
My project is only pulling in 3 dependencies, one of which is an official golang library, but not in the stdlib (x/sys). The only other two dependencies are Microsoft/go-winio and lxn/win all of these dependencies are not what I would call uncommon.
It does appear that anti-malware software on Windows has a recurring issue with golang binaries:
https://golang.org/doc/faq#virus junegunn/fzf#2002 https://groups.google.com/g/golang-nuts/c/Au1FbtTZzbk
Helpful links though, will help convince other users this truly is a false positive, I'll be putting them into my readme.
How I'm Handling It
I'm recommending to my users who are concerned about this to clone the source code, and compile it themselves. Anyone who trusts that the binary they download from github is safe can just add the executable to the windows defender exclusion list. I'll also be updating the readme to talk about this and link to the official go faq.
I'm experimenting with reproducible go builds (using -trimpath, though I have yet to get two actual identical builds, I don't have access to two windows environments yet). If I'm able to get those working I'll put the checksums for the binaries in the release so more advanced users can compile it themselves and confirm the checksums match.
Ultimately, both our tools are developer focused, so I'm comfortable telling users that this is something they'll have to deal with if they don't want to compile it. Like you, I'm not going to get into signing these binaries with a purchased signing key, I'm not going to spend money to support software I give away for free, especially when it functions just fine.
You can easily report it to Microsoft, they will make an exception. https://www.microsoft.com/en-us/wdsi/filesubmission (Home User)
They usually respond in 1 or 2 days.
PS: Yes, Windows Defender is creating a lot of false positives... It's starts to annoying.
Also, just now...
Trojan:Win32/Zpevdo.B detected by Windows Defender in https://github.com/benpye/wsl-ssh-pageant/releases/download/20201121.2/wsl-ssh-pageant-amd64.exe
Just reporting that I'm getting the same with the associated image / screenshot from defender
Im getting a similair report from a work system.
Symantec Endpoint Protection marks it as Trojan.Gen.2
McAfee Total Protection detects both wsl-ssh-pageant-386-gui.exe and wsl-ssh-pageant-386.exe as a virus and blocks them.
Mcafee threat prevention show is as ATP/Suspect!6267f6a46157 probably trojan (based on heuristics and reputation)
# FileName (custom) wsl-ssh-pageant-amd64-gui.exe
# HashValue (custom) 5fc26091a978a4c77353bf36ed41ee35
# TargetPath (custom) C:\Users\
# TargetProcessName (custom) wsl-ssh-pageant-amd64-gui.exe
# ThreatCategory (custom) av.detect.heuristics
# ThreatName (custom) Real Protect-SS!5FC26091A978
# ThreatName (custom) ATP/Suspect!6267f6a46157
# ThreatType (custom) trojan
If this was rewritten in another language do you think it would still trigger these false positives? For some reason this seems prevalent with Golang projects
It's possible, Golang does appear to suffer from this a bit more than other languages. Defender at least does allow false positives to be reported, and I did that a few times, but it seems that the false detections come back and I don't really have the time or patience to do it constantly.
It does look like winget deals with this for the packages that are available there. Portable applications weren't supported in the past but it looks like they will be soon - https://github.com/microsoft/winget-pkgs/issues/67263
I'd be happy to support any PR to add wsl-ssh-pageant to winget, and I might try and find some time to. I would be quite happy to get the Defender false positives resolved at least.