Why does my installer get flagged by Windows? | Hacker News Reader

Why does my installer get flagged by Windows?

blog.pakkly.com

108 pointsgrwtr79 comments

It's really annoying we don't have a better solution for this. Even outside of open source, I don't want to spend over $600 up front before I sell a single copy of an app just to stop MS from blocking it. And that's not even mentioning companies like sectigo being terrible at their job. I've spent over a week going in circles with their support about verification: "your license shows address A", "no, the back shows the current address B, it's in the file I sent", "please send us a valid ID with address B", (repeat).

But unfortunately that's just a rant. I don't know if there even if a better solution. The money barrier (rather than verification) will stop some opportunistic malware, but big players won't care.

Even for our company, we would fork over the $600 but it looks like all of the EV cert options require a hardware signing key. Putting a human in the loop for our otherwise fully automated release process is a non-starter.

You can automate code signing using Microsoft azure key vault. I did it last month, no need for a dongle nor a pin number

Also, Microsoft is working on a code signing service called Azure Code Signing where Microsoft issues and manages the certificate and keys and you simply upload binaries/app packages to Azure which does the signing.

As far as I can tell, the video is the only public information on the non-GA service: https://youtu.be/Wi-4WdpKm5E?t=529

That sounds like abuse of a monopoly position to me. They keep the horrendous status quo as bad as possible so their new product looks good by comparison.

I’m ready for bipartisan gutting of big tech.

It's iOS all over again. Computing freedom is something only enthusiasts have now.

So MS sells a solution to a problem they caused? fantastic, whats new.

Sounds like the hardware key requires a pin, but not physical presence (i.e. not a button touch), so it can be automated https://stackoverflow.com/questions/17927895/automate-extend...

One of my clients has strict requirements for an automated build process, and we managed to use an EV code signing cert on a YubiKey w/ PIN - so it’s definitely possible with a little leg work.

After having gone through it, I agree with other posts that the main annoyance is the verification process and weeks of delays/back-and-forth. That, and the inconvenience of now having a single point of failure in the build process (unless multiple certs are purchased).

> inconvenience of now having a single point of failure in the build process (unless multiple certs are purchased).

Except that's not quite true is it.

Most (all ?) devices (even the cheap USB ones) have secure wrapped backup/restore mechanisms.

All you had to do was set up your device correctly in the first place (since the wrapping can't be activated retrospectively).

Some of the cert vendors even have ready-made instructions available to follow on their website telling you exactly how to do this: https://www.ssltrust.co.uk/help/setup-guides/mofn-setup-nitr...

RTFM as they say. ;-)

Correct me if I'm wrong, but when a fully preconfigured YubiKey is shipped to you as part of the EV cert fulfillment, then there is no way to do this after-the-fact.

> Putting a human in the loop for our otherwise fully automated release process is a non-starter.

I don't follow.

The purpose of storing keys in hardware is to irreversibly protect the key.

If you then wish to be silly and hardcode the PIN to the hardware in your release scripts, then that is your prerogative.

If its the cost of an HSM you're alluding to, even that is a non-issue with a Yubikey or Nitrokey.

Worse still, the SafeNet software that my cert vendor recommends using (to interact with the hardware key) doesn't even allow use of Remote Desktop sessions!

It somehow detects if you're in an RDP session, and shows that there are no hardware tokens attached if that's the case. No message or warning whatsoever. My only Windows PC is headless and I lost several hours trying to debug this.

The entire EV cert process is such an outrage. My cert vendor advertised that the validation process would take 2-3 business days if all docs were in order, DUNS info correct, etc. I spent a lot of time ahead of the order ensuring the docs were indeed in order, and the process still inexplicably took 9 business days.

Maybe try something like TeamViewer since rdp virtualizes the display adapter and likely other things

It's not about virtualisation. RDP sessions are actually marked as remote login sessions. The login source can be checked easily in each app. (or just run `net session`)

If TeamViewer acts on an already logged-in local session, it should work well.

One way around SafeNet is to run the builder in a VM, then RDP into the host.

or use vnc, teamviewer, etc

Oh man I totally got hit by that and never did figure out being in rdp was the reason!

Can you use a VNC server instead as a workaround, or does it detect that too?

You can wire up a microcontroller to push the button as part of your CI/CD.

This is a hilarious solution that I would love to see gain popularity. Lol.

People are actually using it. I have some vague interest in Windows driver development and this hardware token requirement hit there first.

Back in 2014 I was working at AltspaceVR (a social virtual reality startup) and we had Mac and Windows versions of the product. I set up a Mac Mini at the office to do the Mac builds, and it also ran a Windows VM under Parallels to do the Windows code signing. (The actual Windows builds ran in the cloud and we sent them down to the Windows VM for signing and then it sent them back up to the cloud.)

We had a Digicert code signing certificate that used a hardware key connected to the Windows VM. Unfortunately it required a password to be manually entered each time the code was signed.

To automate this, I wrote a little AutoHotkey script that watched for the password dialog and entered the password.

There wasn't any RDP issue because we didn't use RDP, just a Windows VM that didn't need any user intervention. (It could have been a separate physical machine, but since we had the Mini anyway and it had the capacity, it was convenient to have it do both the Mac builds and the Windows code signing.)

I sometimes think there are few problems that AutoHotkey cannot solve.

Agreed, AutoHotkey is awesome!

Of course, there's a kinda reasonable reason for the hardware token requirement: Widely publicised 2010 virus 'StuxNet' had a driver signature, using a stolen copy of Realtek's driver signing certificate. [1]

And stolen certificates make the whole code-signing house of cards falls apart - you can't trust something signed by Realtek if it was not, in fact, signed by Realtek!

Of course, hardware tokens aren't a panacea: Some malware authors simply set up a shell company and get a certificate issued to that company.

[1] https://www.trendmicro.com/en_us/research/18/d/understanding...

You need the key, but there are ways to get a .pfx out of it. Which I unfortunately don't remember, but that is probably documented by whoever you got the key from. And otherwise signtool can be used with the key, though it is not always trivial to get working.

yeah, i thought this too but it was really easy to automate

Why doesn't Windows (Microsoft) build open source code themselves and sign the source seen, easier to inspect for bad things version?

It's not easy to spot malware, even if you have the source. For example Zoom can capture your screen, start applications, capture mic and camera, and allows remote control of your desktop. Why wouldn't it be blocked as malware even if you could automatically inspect the source?

Automated malware detection typically looks for behavior during installation rather than just the payload. (You can use the payload as a hint, though.) If an installer downloads a PNG and injects the last half of it into another process, and that drops an unsigned EXE into 'all users\startup' that can capture your screen, etc. you can probably block that without pissing too many people off. If you block SCREENCAP.EXE it's a different story.

That's old news. The race happens every day. AV companies upload samples to explode in a simulated environment, meanwhile malware authors started fighting back using `sleep(10000)` to avoid detection since that's longer than automation is worth running. The bad parts are not being executed until much later. Then the test environments started faking time speed ups.

I think there was a good episode about that in the Risky Business podcast.

Regular code signing cert is often good enough.

The entire point of the article is that it is not good enough though.

This was my experience (regular cert not good enough)

And here I am telling you I've done this and it has worked and continues to work today.

Do whatever you want with that information.

And here I am telling you I've done this and it didn't work. The EV cert worked a lot better.

Do whatever you want with that information.

That's too bad. I see why you're angry. Good luck!

FTA btw "Essentially you have the option of two different kinds of certificates and three different price levels, depending on your urgency and user sensitivity."

Maybe you need to change something about your application.

No luck needed. The EV cert works great.

And to be fair that is very much _not_ the entire point of the article.

"Essentially you have the option of two different kinds of certificates and three different price levels, depending on your urgency and user sensitivity."

We had to manage flagging problems at my company and even though we now sign our installers with a EV Certificate, anti-virus software have their own reputation database and still flag our work until a certain amount of users install it

And that’s before Windows Defender falsely identifies your executable as a random threat and moves it to quarantine without asking. Who do you have to bribe to prevent that?

This does seem to happen far too many times than it should and it can get frustrating.

Over the period of several years this happened to me on at least half a dozen occasions and recently in a two week period it happened three times.

Fortunately, in my experience this has always been fairly easy to fix, as it just requires submitting a false threat report to Microsoft Defender:

https://www.microsoft.com/en-us/wdsi/filesubmission

Each time this happens I just copy my stock standard false report into the fields of that link and within 24 hours Windows Defender is updated.

Reminds me of a Coding Horror (?) story where a client kept asking the developer to have their app window be on top (most visible.) Poor developer kept trying to explain that whatever method they used to be on top, anyone else could use to be also on top of their app.

Anyways, there is no general heuristic to distinguish a good actor trying to prove their legitimacy from a bad actor trying to fake legitimacy. This is the essence of parasitism.

Close - Raymond Chen

https://devblogs.microsoft.com/oldnewthing/20110310-00/?p=11...

this post is a treasure, thanks for sharing.

walls and ladders - ill remember that.

He also calls Windows security an "airtight hatch" and I laugh at the hubris.

Not really. Here is what he actually wrote:

https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

He doesn't quite come out and say what "being on the other side of this airtight hatchway" means - it appears only in the title. But the post makes it clear what it alludes to: if you're already in a position to execute arbitrary code on the target machine in the security context you want, then you don't need to jump through further hoops, because you're already there.

It's a Hitchhikers Guide to the Galaxy reference.

That's a much better written (and backed up) story than the one I remember, which I recall being in the Coding Horror "fireside tale" style. Maybe Raymond's was the original!

>Who do you have to bribe to prevent that?

It's covered in the article: buy an EV code signing certificate.

These are different things. SmartScreen can be solved with a certificate. Being classified as a virus/malware is a separate process.

Same thing is happening to the web: I put compiled executables in a zip on my website and Chrome flags them as "unknown / untrusted" with a few hoops to download and run it. I understand the advantages of protecting naive users from malware but this is really going to hurt small / independent software developers.

It also drives them to stores which take a significant financial cut.

Yeah... the slippery slope into the walled garden continues.

More like a trapdoor in a lot of ways.

Without a cert etc most people shouldn't be installing the applicarion at all. Thats the simple advice for most people, especially if some other trust is already in place, eg from someone you actually trust.

Also: Buy a the longest code signing cert you can. Reputation is acquired at cert and build level; updates signed with same cert are cleared much much faster. Cert reputation is lost when it expires, meaning back to square one to sign updates.

So reputation is the word we're using to mark sanctioned applications these days. Funny, I always think of reputation as a scale, not a boolean.

Also, this remains a constructed industry with only marginal benefits and major issues. Anyway...

Even just to avoid the pain of acquiring the certificate on a yearly basis.

I've never had a smooth ride getting a Code Signing Cert, always some stupid bureaucratic rubbish to deal with, or the need to run some stupid obsolete browser in order to actually get the thing, and I know at least 2 others who also ran into the same crap.

Yes! This as well.

Getting code signing certificates is trully a "blast from the past" - it gets you feel the pain of SSL certificates before Let's Encrypt was a thing.

LPT: put your executable binary on GitHub/GitLab/SourceForge/... These locations are whitelisted since they have a ton of fresh binaries.

Malware writers use this trick to bypass SmartScreen. Chrome's equivalent protection also whitelists GitHub/...

Not sure this works. Just grabbed a build of WhyNotWin11[1] released 20 hours ago, and I get "Microsoft Defender SmartScreen prevented an unrecognised app from starting. Running this app might put your PC at risk."

[1] https://github.com/rcmaehl/WhyNotWin11 (used for test as I thought I remembered seeing this with a build from earlier this week)

I don't think that works, as I had an app hosted on GitHub, a signed one actually, and it was still showing the SmartScreen warning at first. It took a few days to go away.

Well that's actually pretty concerning, and it only shows how broken these "security" "features" really are.

No, this definitely doesn't work, random installers and executables downloaded from github.com definitely show the SmartScreen popup.

That's my experience as well. I think that after enough people install something, Microsoft starts trusting it, so it's usually fine for a major release of a popular package. Nightly builds of less popular packages? I always get the popups. (Although oddly, not on any of my projects that I release Windows binaries for...)

Off-topic: I was giving a presentation and needed to download something from microsoft.com, it was a wsl update or something. After download MS-Edge marked it as dangerous and harmful. Needless to say the audience bursted in laughter and I was able to convert some people to Firefox that day.

Be warned: EV-code signing certificates do not work as advertised. There is no instant reputation. My company tried this and it does not work.

I'm not sure what to do anymore. We are a small company with few customers. Slowly gaining reputation over time does not seem like a viable path.

Also a small company. The ev cert worked for us. Are you having trouble with smartscreen or av products?

That is great news. Maybe there is a difference in provider? Or perhaps we wasn't patient enough.

We have problems with smart screen.

Can you recommend a certificate provider?

We used digicert. There is a 50% off link if you Google around for it

Thanks!

All this does is train people that they have to fight with someone that "knows better than them" every time they need to do anything useful. The one channel they had to communicate with users and warn them about threats is now gone, I hope they're happy.

The installer gets flagged because the game isn't Security, it's really Compliance.

I'm thinking of FTC and oligopoly.

Nice article!

A few years ago I had to go through the process of getting a certificate for signing Windows application. I provide some details here: https://henvic.dev/posts/cs-security/

Even Microsoft own software must go through this. Try to download dotnet SDK ci build and you will have the same thing.

Somewhat related: I would really like some sort of OS-wide flag informing all apps and websites that, yes, I understand what a hyperlink is, it is not necessary to warn me when I click one that it will take me to a website.

It's an extortion racket. They want you to go through Windows Store.

Reply on news.ycombinator.com