NSIS and nsis-web Installers are being detected as: Suspicious.Win32.Save.a false positives with VirusTotal

[cliqer]

• Electron-Builder Version: 22.14.4
• Node Version: 14.17.6
• Electron Version: 15.1.2
• Electron Type (current, beta, nightly): current
• Electron-updater: 4.3.9
• Target: nsis / nsis-web / x64

These are EV Signed executables where NSIS and nsis-web Installers are being detected as Suspicious.Win32.Save.a from Sangfor Engine Zero with virus total: https://www.virustotal.com/gui/file/caed701727fa4f7805e2ddae9b0a28ec02e07fc6636f9df8da1b748d164583bd?nocache=1

Uploaded and checked each file on its own and none returned as a virus; then created a nsis-web and uploaded only the installer that flagged as one immediately: https://www.virustotal.com/gui/file/eb4ebdce32741e4b29f8845fbb54c30022ab7f63bbe90543eccb593ff3cbb414?nocache=1

So it seems something within the installer gets reported as a threat. Would you please advise of where the problem may be?

Building from an arm64 M1 machine using the latest parallels and Windows 10 Pro Build-21390

[cliqer]

WinShell.dll is the file that flags installers as malicious: https://www.virustotal.com/gui/file/9be85b986ea66a6997dde658abe82b3147ed2a1a3dcb784bb5176f41d22815a6/detection

Please replace asap

[cliqer]

It is downloaded from here: https://github.com/electron-userland/electron-builder-binaries/blob/ec807af771a341b93d122734a9a1d6d2ae9bf90a/nsis-prepare.sh

[mmaietta]

Odd, that file hasn't been changed since 2019.

@develar what's the best way to proceed here? Should these dll's be stored in the repo itself? It seems using a live download link has introduced a vulnerability (not sure how recent either, but seems to persist back through electron-builder v22.10.5: https://github.com/electron-userland/electron-builder/issues/6347#issuecomment-945154191)

curl -L http://nsis.sourceforge.net/mediawiki/images/5/54/WinShell.zip > a.zip

Please advise/act asap since I can only modify this project's repo

[lemueljay]

Same issue experienced. My installer with a signed certificate was flagged with Suspicious.Win32.Save.a from Sangfor Engine Zero with Virus Total.

NodeJS Version: "14.17.6" electron-builder: "22.9.1" electron: "11.0.3"

Following this for possible resolutions.

Thanks!

[cliqer]

Thank you @mmaietta & @develar.

I see that there is a new tag nsis-3.0.5.0 binary available: https://github.com/electron-userland/electron-builder-binaries/releases/tag/nsis-3.0.5.0

When extracted the plugins folder does not contain WinShell.dll and, after checking each of these files with virustotal, they are not getting flagged.

Any chance this is the solution and that the NSIS binary just needs to be replaced within electron-builder?

[mmaietta]

@cliqer great callout! Would you mind trying this change to node_modules/app-builder-lib/out/targets/nsis/nsisUtil.js to utilize the newer makensis and report back? If that works, happy to get that fixed up and a release out quickly Change:

return binDownload_1.getBinFromUrl("nsis", "3.0.4.1", "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==");

To:

return binDownload_1.getBinFromUrl("nsis", "3.0.5.0", "cTeQgtymnETCMGZa89l5A790zw4otqFThfQbm52AbhUtPUD2yp2lmmu/T9Hd6fG/rDej0o6X6OTupxZB3n8HbA==");

Note, it's also possible to build using a local download/version of makensis using env.ELECTRON_BUILDER_NSIS_DIR

[cliqer]

@mmaietta Tried your suggestions and now three threats are being detected with virustotal: https://www.virustotal.com/gui/file/9c96d2f97bce7e75fcc738531920d981a7b38f92ba52bfe30c14b78d48ebcbbe?nocache=1

Antiy-AVL -> Trojan/Generic.ASMalwS.3100239
Jiangmin -> Adware.Agent.aozt
Sangfor Engine Zero  -> Suspicious.Win32.Save.a

It looks like some malware is using electron with NSIS and antivirus engines have blacklisted the installer for everyone :/

BTW there is one more location that is using the 3.0.4.1 resources and downloads the following:

  • building        target=nsis file=build/Cliqer-1.3.12-win-x64.exe archs=x64 oneClick=false perMachine=true
  • downloaded      url=https://github.com/electron-userland/electron-builder-binaries/releases/download/nsis-3.0.5.0/nsis-3.0.5.0.7z duration=644ms
  • downloaded      url=https://github.com/electron-userland/electron-builder-binaries/releases/download/nsis-resources-3.4.1/nsis-resources-3.4.1.7z duration=588ms

Maybe the nsis-resources-3.4.1 contains the problematic files but didn't check in-depth yet.

[cliqer]

@mmaietta Yes, the problem is within the nsis-resources-3.4.1. The following files are getting flagged:

x86-ansi
- nsisunz.dll
- UAC.dll
- WinShell.dll

x86-unicode
- SpiderBanner.dll
- UAC.dll
- WinShell.dll

Also shouldn't we use the latest NSIS v3.08 while we are on it? https://sourceforge.net/projects/nsis/files/NSIS%203/3.08/

[mmaietta]

Also shouldn't we use the latest NSIS v3.08 while we are on it?

I agree that would be ideal. The nsis needs to be recompiled with both extended length strings and debug flags enabled. The hard part is finding a device to do it, it didn't compile for me. My hackintosh and m1 mac's weren't able to, I imagine an intel mac could or perhaps use the linux script. This was an issue opened for updating nsis: https://github.com/electron-userland/electron-builder-binaries/issues/42

I honestly have no idea how nsis installers work or what files we need. For instance, why do we have WinShell? I'm not sure I understand these nsis-resources

[cliqer]

@mmaietta For the time being if we can somehow replace/remove the use of nsis-resources-3.4.1 it compiles correctly with nsis-3.0.5.0.

The nsis needs to be recompiled with both extended length strings and debug flags enabled. The hard part is finding a device to do it, it didn't compile for me.

Tried to figure out how to do that within app-builder-lib/nsisTarget.js but I didn't succeed... I do have an intel mac to use or maybe Github actions could be of help.

Do you know, and if so, can you share what needs to be compiled for me to give it a shot?

ps. there is a brew of makensis for arm64 if that helps

[mmaietta]

@develar can you please advise here?

• What is winshell.dll being used for in nsis-resources? Is it needed for something specific?
• Can we get it from elsewhere? (I haven't found any) As the current Sourceforge download link has this Suspicious.Win32.Save.a detection in the payload.

@cliqer , thanks for all your investigative work here, I really appreciate it. We can use nsis-3.0.5 for sure, but I'm not sure if that completely removes the need for nsis-resources. If you're willing to, I'd be happy to review a PR on the nsis update! Setting up a local dev environment is pretty simple: https://github.com/electron-userland/electron-builder/blob/master/CONTRIBUTING.md#to-setup-a-local-dev-environment

[cliqer]

@mmaietta @develar, tried but failed to figure this out. A little help please.

[wonkyungup]

@mmaietta @develar, I can't solve it either. help me.

[sr258]

Our app has the same issue: https://www.virustotal.com/gui/file/6bafe31fc834c85a785b89aee462ee039a5dbd9b75dbc3b64c4164c80abf3476

In our case SpiderBanner.dll is flagged by SecureAge APEX and the Uninstaller.exe by Sangfor Engine Zero.

[cliqer]

You can omit the SecureAge APEX flag if you purchase a certificate and code sign your app though nothing will change until someone manages to update NSIS and remove these ancient files that throw these warnings. TBF, Sangfor is basically a scam engine that opens virtual boxes with win7 when testing and flags files so people buy their software.

[sr258]

Thanks for the info! We've put off buying a EV certificate for some time now... Looks like we have to do so after all.

Can I help with compiling NSIS? I have a Win 10 and Linux machine and macOS M1 at my disposal.

[cliqer]

It is not that easy unfortunately (I have tried) and many files need to be amended from @develar which have not responded for 18 days now in this critical issue. Donating since the beginning didn't work either so not much to do actually.

About code signing, EV's create more problems than they solve and you can't automate or remote build as you need to put the password manually multiple times per build (at least 4x). Just get the cheapest code sign cert you can find and you'll be fine.

[davej]

About code signing, EV's create more problems than they solve and you can't automate or remote build as you need to put the password manually multiple times per build (at least 4x). Just get the cheapest code sign cert you can find and you'll be fine.

Off-topic: you can deploy an EV cert to a cloud hosted HSM and use that to sign remotely. You can set it up yourself but it will take some work or you can use ToDesktop CLI (full disclosure: I founded ToDesktop).

[mmaietta]

Does anyone know what the resource files are used for? I'm wondering if we can just omit them entirely (they look like they're important.) or if we just need to remove WinShell.dll to remove the vulnerability. I just don't know what might depend on it.

The nsis-resources dll files can be found here if you're interested: https://github.com/electron-userland/electron-builder-binaries/releases/tag/nsis-resources-3.4.1 Screenshot below

If we are to move it, then I'm guessing the next best bet might be for me to fork the electron-builder-binaries repo and just maintain all assets there (so that we can remove just WinShell.dll) That or find a way in electron-builder to filter out that specific plugin during nsis creation.

[adimorariu]

Electron-Builder Version: 22.13.1 Node Version: 14.17.5 Electron Version: 15.3.1 Target: nsis

Having a similar issue: We use Angular 12.x for the renderer part,

• if I include the date picker from angular material and I try to build as nsis, Windows defender detects "Trojan:Win32/Bulta!rfn" threat
• if I try to build as portable everything works fine without windows defender giving a false positive
• if I don't include the date picker component it works just fine to build nsis package

I need to mention that I tried using some third party date pickers instead of the one provided by angular material and I got the same results

[JCMais]

I am also having the same issue. The setup file created by NSIS is being reported as a Trojan:Win32/Bulta!rfn by Windows.

This seems to be caused only with nsis 3.0.4.2, and not 3.0.4.1. Currently we had to downgrade to electron-builder 22.3.6, which is the last version that used 3.0.4.1.

[adimorariu]

Downgrading to electron-builder 22.3.6 works for me too even if I include date picker component. Again, what is odd is that even with electron-builder 22.13.1 it works if I don't include the date picker component :)

[mmaietta]

You can easily test if NSIS is the core issue by using any of these lines in node_modules/app-builder-lib/out/targets/nsis/nsisUtil.js

return binDownload_1.getBinFromUrl("nsis", "3.0.5.0", "cTeQgtymnETCMGZa89l5A790zw4otqFThfQbm52AbhUtPUD2yp2lmmu/T9Hd6fG/rDej0o6X6OTupxZB3n8HbA==");

or

return binDownload_1.getBinFromUrl("nsis", "3.0.4.2", "o+YZsXHp8LNihhuk7JsCDhdIgx0MKKK+1b3sGD+4zX5djZULe4/4QMcAsfQ+0r+a8FnwBt7BVBHkIkJHjKQ0sg==");

or

return binDownload_1.getBinFromUrl("nsis", "3.0.4.1", "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==");

[cliqer]

@mmaietta the issue has already been established for quite some time and an update of NSIS is urgently needed. Many things have changed and we need a core developer of electron-builder to get involved with this issue and implement these changes.

[JCMais]

@mmaietta NSIS is the issue. I got it to work without the trojan warning by downgrading the NSIS version to 3.0.4.1.

This can be done by adding the following to the build configuration in the project's package.json:

        "nsis": {
            "customNsisBinary": {
                "url": "https://github.com/electron-userland/electron-builder-binaries/releases/download",
                "checksum": "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==",
                "version": "3.0.4.1"
            }
        },

3.0.5.0 is not working due to a build error.

[mmaietta]

Thanks @JCMais, great call on using the customNsisBinary config for testing with!

@cliqer community PR contributions are always encouraged 🙂

Will publish a release shortly with nsis downgrade.

[JCMais]

thanks a lot @mmaietta

[mmaietta]

Pushed release 22.14.8 w/ electron-updater@4.6.3

[arsinclair]

@mmaietta NSIS is the issue. I got it to work without the trojan warning by downgrading the NSIS version to 3.0.4.1.

This can be done by adding the following to the build configuration in the project's package.json:

        "nsis": {
            "customNsisBinary": {
                "url": "https://github.com/electron-userland/electron-builder-binaries/releases/download",
                "checksum": "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==",
                "version": "3.0.4.1"
            }
        },

3.0.5.0 is not working due to a build error.

@JCMais I don't think this workaround is actually working. I added some random characters to the url, expecting it to fail the build if a custom NSIS binary is not found, but the build succeeded anyway.

I tried adding this config both to package.json and to my electron-builder config file, in the nsis section, however none of them is failing the build.

Do you have an idea why this might be happening?

[JCMais]

Not sure if it will fail the build or just use the default value if the one provided in the package.json is invalid. Changing it like that is working for me.

You have to add it inside the build property of the package.json. It will be something like:

    "build": {
        // ... other options
        "nsis": {
            "artifactName": "${productName} Setup ${version}.${ext}",
            "customNsisBinary": {
                "url": "https://github.com/electron-userland/electron-builder-binaries/releases/download",
                "checksum": "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==",
                "version": "3.0.4.1"
            }
        }
    }

[arsinclair]

Not sure if it will fail the build or just use the default value if the one provided in the package.json is invalid. Changing it like that is working for me.

You have to add it inside the build property of the package.json. It will be something like:

    "build": {
        // ... other options
        "nsis": {
            "artifactName": "${productName} Setup ${version}.${ext}",
            "customNsisBinary": {
                "url": "https://github.com/electron-userland/electron-builder-binaries/releases/download",
                "checksum": "VKMiizYdmNdJOWpRGz4trl4lD++BvYP2irAXpMilheUP0pc93iKlWAoP843Vlraj8YG19CVn0j+dCo/hURz9+Q==",
                "version": "3.0.4.1"
            }
        }
    }

Good point about build property, I didn't do that in the initial test. I tried now, though, and it still doesn't fail the build.

For now I have upgraded to the pre-release version of electron-builder where this is fixed, so this is not relevant for me anymore, but thanks for your help!

[leovarmak]

Guys any luck here? Is there any other option apart from downgrading?

[wesinator]

The latest scans as of 2023 do not have detection results.

It would probably be best to upgrade NSIS in electron-builder, to use 3.09.

Also, it probably isn't worth not upgrading to a newer NSIS package just because one low-quality AV engine has a false positive on any NSIS executable.

[mmaietta]

To upgrade makensis, please consider contributing to this repo https://github.com/electron-userland/electron-builder-binaries, then I can open a PR for electron-builder to update it's nsis binary configuration