Apache on clients seen as a security vulnerability - can't update it

[VintageMacGuy]

We have a security scan that is showing we have an unpatched version of Apache on our client Macs. It's not running. But the fact that it is there at all shows it as a security issue. I have been looking for a way to get it updated to resolve the vulnerability, but it appears that it is only updated via Security Updates from Apple. And Apple is not keeping current. Even the new Monterey OS that came out this week has an old version of Apache in it and no way to upgrade.

Our solution was probably not the best, but seems to work. We just removed the Apache folder from the client systems via a policy.

We created a new policy, scoped it to where we need it, set it to run once a day at check-in and configured Files and Processes to Execute Command:

sudo rm -rf /etc/apache2/

This removes Apache and the vulnerability scan comes back clean now. I wish there were an easy way to patch the built-in Apache, but Apache.org has no Mac updater, and Apple said they don't support it - check with Apache.org (who has no support other than community support via Usenet or a mail list). So this was our un-elegant solution. I hope it saves someone else some time.

[ljcacioppo]

Is system integrity protection disabled on your computers? I had thought apache was in a SIP protected directory.

Also, apache is inert on macOS by default, so although it may exist on machines, it is not actively running by default.

Yes, Security Products may flag apache as unpatched, but it is built into the operating system and has to be updated by Apple. Explaining this to your security team may be the better method.

[VintageMacGuy]

SIP is not disabled. Yes, Apache is not running. My security team came up with this suggestion and tested it to make sure it worked.

[boberito]

File feedback, open tickets with enterprise support with Apple. About all you can do.

[VintageMacGuy]

I don't think Apple runs on our timeline though. 🙂

[tlarkin]

It is SIP protected and the vulns really only apply if you are running the service and accepting incoming connections, but vuln scanners don't know or care about this. You are at the whim of Apple to patch this. I suggest engaging with your security teams and asking them to build a process for SIP protected binaries that cannot be patched, nor can be deleted.  We mark those as lower severity to extend SLA or we mark as will not fix and move on.

[VintageMacGuy]

I thought it was SIP protected too - until our head of Cybersecurity tried deleting it on his, ran a scan afterwards, and said that is scanned clean. We don't have the other options you mentioned.

[tlarkin]

Well, I am not sure what your cybersec folks expect.  Your security teams should be able to evaluate vulns and assess risk, that isn't IT's job. Also, this can be compensated with firewall controls, i.e. enforce strict mode and block all incoming connections. If you don't build a process around this, you will be fighting this for the rest of your lives. As in the end you are at the mercy of Apple patching. So, I would strongly encourage you socialize these ideas with your security teams and see about how you all can work together to build a process.

[Donnie7355]

Thanks to this article I can learn more. Expand my knowledge and abilities. My Balance Now

[VintageMacGuy]

Quick update - the command ran and the vulnerability scan ran afterwards and a little over half the machines now passed the scan. Checking into why the others still failed. All are running Big Sur 11.6.

[talex365]

Won't that directory just come back with the next major release (assuming next year sometime)?

[VintageMacGuy]

We created a new policy, scoped it to where we need it, set it to run once a day at check-in and configured Files and Processes.