Attackers spread backdoor via eScan antivirus software update process | Hacker News Reader

Attackers spread backdoor via eScan antivirus software update process

decoded.avast.io

57 pointsskilled56 comments

Antivirus being not only inherently ineffective, but actively undermining the security of the system through negligence and poor practices. Often tampering with other software and negating actual security hardening measures along the way. Has anything changed this past decade or two?

https://ia801200.us.archive.org/1/items/SyScanArchiveInfocon...

https://robert.ocallahan.org/2017/01/disable-your-antivirus-...

Anti Virus is a net good, although the entire OS industry understands that it is an outdated way of thinking about endpoint protection. You could say what you said about lots of software, including almost anything with a built in updating feature.

That in mind, there's no reason to use anything but Windows defender on Windows (unless youre a high value target)

No, the same can't be said about other software. No other kind of software runs with kernel privileges and goes out of its way to touch everything within sight, be it files, sockets, devices, or processes. No other kind of software disables or gets in the way of implementing hardening measures of other security critical software. No other kind of software messes with browsers and OSes, and at the same time, invest so less in making its architecture and implementation at least as secure as the thing they're messing with. Well, maybe except other user hostile software like malware and DRM. Antiviruses dramatically increase the attack surface of the system, both in theory and practice.

Even an antivirus without the flaws isn't much useful. It's in essence solving the halting problem. Only worse because instead of determining whether a program halts, antiviruses seek to determine whether a program is "bad." A vague criteria that even human beings have trouble defining let alone come up with an algorithm for it.

Many of these issues are inherent to antiviruses. Windows Defender, coming from an OS vendor, may perhaps be better in terms of implementation. However, even good implementations can’t overcome fundamental problems that stem from the very idea of the software itself.

No. The only thing that the antivirus is doing is actively preventing the user from doing work.

If you're gonna use an antivirus just use Windows Defender. There really isn't a reason to use anything else these days.

Is Windows Defender really effective in 2024? You would think any virus designer would design their stuff in a way that the default antivirus built into the product they are attacking wouldn't be able to find it...

And before you say "well duh, but signature updates", I will respond with the fact that nearly malware is designed to auto-update... And will obviously make sure that the windows defender signatures fail to auto-update...

> Is Windows Defender really effective in 2024?

Yes.

> You would think any virus designer would design their stuff in a way that the default antivirus built into the product they are attacking wouldn't be able to find it...

You would think that Microsoft would build mechanisms to prevent this. And they do. Avoiding detection is a key goal, to be fair.

> And before you say "well duh, but signature updates", I will respond with the fact that nearly malware is designed to auto-update...

That's actually very noisy, and an important part of modern malware is avoiding detection - internal and external. Auto-updaters are pretty easy to detect. Even large ISPs will look for auto-update traffic and alert their customers (or in some cases, disable their accounts temporarily!). And once detected, these companies are very well practiced in taking down the hosts of the updates.

So that is a "fact" but it's not so black and white :)

> And will obviously make sure that the windows defender signatures fail to auto-update...

Sounds easy in theory, very hard in practice.

On modern systems, requires kernel mode/system/specific elevated privileges. Using a kernel exploit is rare because they're hard to come by and very valuable - limits scope of who an attacker will bother wasting one on. UAC will complain that an unsigned binary is trying to elevate, and such functionality may even be disabled. In fleet machines, the user often cannot escalate their privileges in such a way that allows defender to be disabled.

Anti-virus is still relevant and useful, although slowly fading into irrelevance - although there will always be a need by vendors to remove malicious software.

>Is Windows Defender really effective in 2024?

Relative to what?

The question is: are the competitors more efective in 2024 for the money you pay VS the built-in solution, while also using less resources to boot that Defender?

That's the question people and bean-counters ask before pulling out their wallets.

Do you know what’s better than one antivirus software? Two antivirus softwares. I would not want to calculate the extra cost of additional servers to handle loads from each server just wasting cpu running AV software.

You forgot the /s

It certainly ain't the question the IT department is asking in my experience.

All sane virus designers test their creations against all the leading anti virus software.

AV software will only detect known viruses for which a signature exists, or poorly coded/tested ones that are caught by AV heuristics.

> Is Windows Defender really effective in 2024?

relative to what?

> You would think any virus designer would design their stuff in a way that the default antivirus built into the product they are attacking wouldn't be able to find it...

Why can't that also be true for any antivirus? I would be shocked if that anyone who still makes viruses wouldn't check virus total first

> > Is Windows Defender really effective in 2024?

> relative to what?

Compared to F-Prot for DOS, Windows defender is a parody.

No. Malware can easily run. It only prevents cracks from running.

Windows Defender still flags every other non-trivial Go binary

Even if it's just 50 lines that were compiled 2 seconds ago by you in the same folder.

Then again, developing anything on Windows seems to be an up-hill battle from the get go

> Windows Defender still flags every other non-trivial Go binary

I believe that is an issue with using reputation based protection rather than an issue with antivirus heuristics, unsigned/unknown binaries get flagged.

I'm interested to know how eScan, a security company, never noticed that they were using http to distribute executables to customer devices for so long.

http or https doesn't matter (in fact, you shouldn't rely on it because the end user could be MITM'd already with a root certificate maliciously installed on their device).

You should sign binaries and verify and consider the network/distribution method compromised by default.

> the end user could be MITM'd already with a root certificate maliciously installed on their device

If a malicious root certificate is installed, then the user’s system is already compromised and signature validation won’t help.

Not in the strict sense if it's state-mandated MITM (you are forced to install a specific root certificate to legally connect to the internet).

But also in the other case, not all is lost: Not every malware can (or even tries to) defend itself against any antivirus software in existence. The machine might be compromised, but being able to retrieve the correct upadate for the hypothetically unaffected malware scanner can still give you the signal that your machine is infected and you should reinstall it.

If the user is MITM'd, what's preventing the attacker also replace the signature to verify against?

The signature would use asymmetric encryption, so unless the attacker had access to the signing key, it would be impossible for the attacker to sign a modified version of the payload.

EDIT: I see what you mean. radicaldreamer stated that a malicious root certificate is installed, but signature validation wont help there. But, it will help when downloading from mirrors or HTTP.

You verify against the signature that's in the current version. Now this may mean that you need to do stepped upgrades to versions that are cross signed to get new certificates. That or you have at least one https update method that gets a signing cert for the application.

And how do you ensure the integrity of “the signature that's in the current version”? Because live patching the signature in a program to force verification of an invalid payload is exactly how many software/game cracks work.

I mean, if you can't verify the integrity of the application you're already running then it's already game over. You're talking about downloading another executable and running it to life patch which is the exact opposite of what I'd suggest.

The currently running (trusted) executable downloads and verifies the signature of the binary. Then after verification you execute it. If your trusted binary is validating invalid data then you've already messed up somewhere.

Re-read the thread, because you're misunderstanding the threat model here.

The starting point was: an attacker has control over the system so that “the end user could be MITM'd already with a root certificate maliciously installed on their device”.

In that case, there's nothing “trusted” on your machine anymore and all bets are off. Doing signature verification in app instead of relying on HTTPS is security theater[1].

[1] or it could be “defense in depth” but that's an argument I'd only accept from someone who really understands what they're talking about, and only in a context where everything else being being done properly. Most of the time “defense in depth” is just an argument for the security theater.

Some customers actually ask for it. The correct behavior is to have https as the default and have the user explicitly switch to http.

Or just validate the binary you download then none of this even matters—for this or any other sort of potential vulnerability, your updater will never end up running untrusted software with escalated privileges.

HTTPS is providing confidentiality, and authentication.

The confidentiality doesn’t really matter here. You’re distributing a software installer. There’s a good chance you’ll give a copy to anyone that visits your website and wants to use your software. And you’re not hiding what you’re downloading in any meaningful way.

The authentication is important. That prevents someone from, say, sending the user a completely different binary and having your software run it.

The authentication could just as easily be solved by signing the files you distribute and validating the signature of the downloaded update before running it.

(Hell, if you’re signing your installers (likely) it could be as simple as deferring to Windows’ WinVerifyTrust method and a check that the certificate used is actually your own.)

Debian still distributes packages primarily over HTTP (https://www.debian.org/mirror/list) without issue.

plenty of critical services use HTTP -- maybe exactly because they are critical.. think the scenarios through and that may make more sense..

Common enough to use it.. linux distros frequently distribute updates over http (and ftp). But those are always signed. Something eScan did not do.

Can’t you switch out the signatures inflight, too?

AFAIK, the worst you could do is serve the victim stale (valid) packages, and prevent them from seeing that there are new updates available.

I maintain a (somewhat) popular mirror server at a university, and we actually ran into this issue with one of our mirrors. The Tier 1 we were using as an upstream for a distro closed up shop suddenly, leaving our mirror with stale packages for some time before users told us they never got any updates.

I don't think that would work with most distros, since you're fetching an (also signed) update list and you'd get notified that the update failed due to a stale list, or that the expected updated package was missing on the mirror.

If it’s based on asymmetric encryption, (e.g. RSA, DH etc) and the private key did not leak, then no.

You could, but then the signature check would fail. Usually the public keys of developers or packagers are shipped with a linux distribution.

However, you shouldn't blindly trust in this in "linux" either. The implementation varies between package managers. Eg. DNF in Fedora has signature checks not enabled for local package installations, by default. There is no warning, nothing. If you want to infect new Fedora users, you MITM RPMFusion repo (codecs etc) installation, because that's a package almost everyone installs locally and the official install instructions don't show how to import the relevant keys beforehand. Arch was also very late to the validation party.

How is Arch vulnerable? While I don't have an Arch system handy, I do have a steam deck that I play around with (in an overlay), and I've certainly run into a lot of signature issues due to Valve making a hackish "pin" of the evergreen Arch with signatures in the Valve tree's snapshot being often out of date.

Those signatures are also checked for local installs unless you explicitly disable them.

Pacman has signature checks by default, for over a decade now, I think, but they have been ridiculously late with universal usage of this feature, relatively speaking. They were still barebacking their machines, when everybody trivially knew the internet was serious business and expected signature checks, therefor.

I realize now it was a stupid question, but the excellent refresher and ensueing discussion of edge cases was well worth the downvote someone felt compelled to leave, haha

I'd hope these other critical services at least sign their packages

Yes. But IIRC there have been attacks on Debian package fetching anyways.

Somewhat ironically OCSP.

This has to do with circularity. If you are building a TLS library that needs to fetch OCSP Responses dynamically, you might not have an easy time using HTTPS to do it. Well, obviously you'd have to disable the use of OCSP for validating the OCSP Responder's TLS server certificate, but still you have a re-entrance requirement, and anyways the OCSP Responses are signed. (Or, well, you could use OCSP to validate an OCSP Responder's TLS certificate if you had code to detect a circular dependency, then stop and consider it validated. This would allow the use of OCSP for validating OCSP Responder TLS server certs where ultimately you could use HTTP for a non-privacy-sensitive certificate or where you could elide OCSP Responder TLS server cert validation but still use HTTPS to fetch OCSP Responses so as to provide confidentiality about the server names you're visiting.)

The main reason to want to use HTTPS for fetching OCSP Responses has to do with privacy rather than security relative to active attacks.

It's probably time to revisit this.

Seems like criminal negligence to me.

If an Uber Eats driver poisons your food en route from McDonalds, then McDonalds is criminally negligent?

I mean, I understand HTTPS is industry best practice but the criminals in this story are the actual criminals.

All analogies are flawed but this feels a bit more like the tamper proof labels on products, the antivirus company threw some chicken in a produce bag, and called it good.

At this point a lot of antivirus software is just useless or actively harmful.

Avast actually had a trojan horse product whose main purpose was collecting browsing history for sale to data brokers ... that you paid a subscription fee for.

https://www.ftc.gov/news-events/news/press-releases/2024/02/...

> I understand HTTPS is industry best practice

Right. Unlike your McDonalds example, there is already an industry standard solution to this problem. The software ""engineers"" who neglected to implement it should be found criminally negligent for the harm they caused to their users. I know this is an unpopular suggestion on HN because code monkeys want all the glory of the "engineer" job title without any of the responsibility.

> The software ""engineers"" should be found criminally negligent

Software goes across borders. Perhaps you also think negligent software "engineers" should be extradited or rendered across jurisdictions?

Apart from the fact that Engineer does not have to imply either certified or licenced (the words you should be using if you know anything).

This whole vector (serving malicious updates via MiTM) has been well known for the longest time, with even frameworks such as Evilgrade for exploiting them.

Such an oversight from a “security” company is frankly unforgivable.

Did the editor reign in the original headline?

In my entire career, I've yet to encounter a virus as deleterious in its effect than some of the antivirus software I've seen (Though, having had minimal Windows experience may contribute to this experience).

I've spent literally hours explaining to my users that no, my software was not distributed with a virus; one popular anti virus program had a false positive flagging it as such.

There are public cases of ransomware crippling the whole org for days. Do you have examples of the similar effect of antivirus?

I really love when “endpoint security tools” feel the need to examine every object file and debugging symbol a compiler emits. It really improved the build times /s

security theater

Makes one wonder how poorly designed the software is. Like most antivirus software, it's probably not very good.

Reply on news.ycombinator.com