Skip to main content

Wrong Privileged Binary on Production Systems

· 4 min read
Cichy
Cichy
Maintainer of IanaIO - security

Wrong Privileged Binary on Production Systems​

Note If you haven't read other posts, we strongly recommend doing so to gain a broader and often overlooked perspective on this issue.

  1. [https://security.iana.io/blog/ondistributedcommunications]
  2. [https://security.iana.io/blog/fridaydeploymentsecurityrisk]

You shouldn’t have an internet connected privileged binary running on your production systems, in other words, do not grant kernel-level access to third-party vendors.

In this security issue the case with all endpoint protection solutions in the market today. The case with anything privileged and internet connected. Not limited to endpoint protection solutions. It’s actually worse with endpoint protection because of false sense of security being a “cybersecurity” tool.

This is a wake up reminder that you shouldn’t have an internet connected privileged binary running on your production systems. What was a bad update could have easily been a massive adversary backdoor. A third party vendor will always be the weakest link.

Endpoint protection​

That's not only the case with all endpoint protection solutions in the market today but the case with anything privileged and internet connected. Not limited to endpoint protection solutions. It’s actually worse with endpoint protection because of false sense of security being a “cybersecurity” tool.

Not if you control the deployment of updates. You deploy to test servers. Validate all is good then do full deployment. That is the problem. We no longer believe in test.

How do you control a system remotely if it doesn’t have access to the internet?​

if i know you're going to install binary updates, and i've hacked the sigs, i nicely put a signed binary in the place you expect to find it, and wait for you to install it. it's definitely slower. but really not different.

Yes, but you cannot command and control the system after a malicious binary is installed because the system is not connected to the internet. I’m not following your argument.

i'm assuming in all scenarios, we have firewalls.

the argument is that if that machine is firewalled outbound to connect to a single update server, that's not "wide open".

the only difference between the two techniques is one gets updates slower than the other.

I still think that even in the scenario where your egress is strictly limited to only update servers, that having an egress to the outside world opens up the possibility for compromise of that pathway to command and control. If you have no path to the internet, then there is no path for command and control full stop.

Plus, letting things roll out slower and allowing for a bake in testing (even 24 hours) would prevent many things being discovered before promoting to prod.

if that was true then supply chain attacks wouldn't exist. but they do. i can continue to broadcast information to your machine every time i release a new binary. until you figure out the supply chain is corrupt your machine will dutifully upgrade on schedule

He’s talking about a real time continuous attack with a live connection. You’re talking about a virus.

This is why your production servers should not be connected to the internet.​

No, supply chain attacks are more like malware and less like a virus. And yes, real-time becomes impossible if your server is offline, but then it's also not a target or even useful for an attacke

IanaIO's solution to this is Isolating Critical Systems​

By using IanaIO's Cyber Security Standard, IICSS "IanaIO's Isolating Critical Systems Standard."

Elon Musk confirmed the security issue described by his employee, Christopher Stanley, who is responsible for cybersecurity at SpaceX.

IanaIO's solution for this security issue.​

[link blog iana.io]