I was installing Kali Linux on a virtual machine and I then ran the updates. They failed.
The error message was “499 Update request forbidden by antivirus”. But Kali doesn’t have antivirus running by default.
It turns out that the virtual machine was trying to download a packet from the repository and the AV on the host was recognising it as a virus signature - it was a Wi-Fi cracking tool - and the AV on the host was blocking the download.
Fair enough, the host PC acts as a bridge and all traffic passes through it and fair enough, the AV software flagged the Wi-Fi cracking tool (for Linux) as malware.
What I find interesting is that Kali Linux managed to interpret the AV software on the host blocking the download as different to the network simply being capped or the file not being found. I’m guessing that VMware or the AV software somehow can signal that it was the host av software that caused the problem.
I’ll try doing some research, but it is very interesting. I managed to get around the problem by temporarily deactivating the AV software, downloading the update and re-enabling the AV software, so it was definitely the host AV software that caused the problem.
The only thing that could be better is if Kali said it was the external (host/network) AV that was causing the problem and not some AV running on Kali… I knew Kali didn’t have AV, so I knew the problem lay elsewhere.
Well… one presumes this was a web request to get a file, and the proxy in the antivirus is the one that is changing what would be a 200 OK into a 499 Update request forbidden by antivirus… ? If that’s the case, then it’s more interesting how the antivirus knew it was an update request… based on the URL or what?
To the AV it will just be an http request, so I’m guessing it did some pattern recognition during the download, found something it didn’t like and blocked the rest of the request.
Thanks for the sanity check. I assumed it was somehow checking the download, but was wondering why Kali was reporting the error code, but, as you say, it makes perfect sense if the AV is acting as a proxy.
This is very interesting as I had been looking at Corporate/centralized AV solutions for both VM and physical systems a number of years ago. I was sidetracked on to other personal projects but because I am a heavy user of virtualization still saw a need for such solutions on container-like systems.
Do let us know if you figure this one out. I’ll be especially interested if your own anti-virus has this feature.
This has got me scratching my head too. I would assume that it’s an https request from the VM guest so I would have thought that the host hypervisor would only see the encrypted payload.
Very interesting. What kind of AV software are you using (sorry if you mentioned in OP and I missed)?
Also - the repo that you’re downloading from, is it TLS secured? This makes sense if it wasn’t, changing an HTTP response header is trivial for non-encrypted traffic. But if the repo traffic was TLS secured and the AV software still managed to scan and alter the traffic then that would be very strange indeed.
Normally I set it up as bridged, but I set this one up quickly, just to do some testing on Kali, so I might have accepted a default of NAT. I’ll have to look when I’m back at work.
Curiosity and some spare time got the better of me.
Using windows VMWare Workstation 15 player in NAT mode my AV client kicks in and blocks the download of the eicar test file but in bridged mode (e.g the VM has its own IP on the LAN) the file is passed through to the guest.
Update: Only the http version is detected by the host’s AV, https is passed through so the host OS must be blind to that and unable to intercept the TLS. The guest wont have a trusted root for the hosts AV client anyway.
Screenshot of NOD32 blocking the http version in NAT mode
If eset is anything like Bitdefender you should be able to add the site to a trusted list within the anti-virus and then you can see if it does any further checking.
That one is definately a basic one but it’s likely seeing a file or request passed through the process chain.
So, I’m back at work. Yes, as it was a quick-and-dirty test, I had just accepted the default settings and VMware decided to use NAT. So the hypothesis about the AV acting as a proxy is correct.
