Another week, another exploit in public cloud infrastructure. What’s going on? Overall, what’s broken here are issues in what the industry has dubbed platform-as-a-service (PaaS) aka high-level cloud services. This is a wake-up call for all of us to do better. More on that later, first let’s see details on this exploit.
Who’s affected by OMIGOD?
Open Management Infrastructure (OMI) is a standards-based, non-proprietary, architecture for the management of machines. This exploit affects Linux systems with the Azure OMI agent installed, enabled, and open to connections on port 5986 which is also used for management of Windows machines using Windows Remote Management (WinRM).
Attack surface
- Internet-facing (Inbound): Those who use a remote management server (based on OMI) to manage Linux machines in Azure over the open Internet, and allow anyone to connect on port 5986.
- East-West: Machines inside an Azure VNET or to a connected VNET via VNET peering or other methods, including remote sites connecting over Expressroute, VPN, or Azure Virtual WAN.
The Attack
The actual attack is quite simple:
- Run port scans to find exposed machines that are reachable on port 5986. This can be from the Internet or inside the Azure network, including connected VNETs and on-premises networks.
- Launch attack to exploit the OMIGOD vulnerability
- Move laterally to other VMs in the same VNET and to other connected VNETs to exploit the same vulnerability or launch additional attacks.
Here’s an example attack we ran to show how easy this attack is for an east-west scenario:
- Victim VM – running in Azure VNET 1 shows the OMI software
2. Attack VM – running in Azure VNET 1 shows the root privileges gained by the attacker on the victim and a few benign test commands
3. Results on the victim VM show the output of the attack
How does Valtix protect against OMIGOD?
Valtix Gateways are continuously updated with the latest threat intelligence to detect malicious activity and proactively block them. Valtix Controller runs as a service and continually deploys these updates to Gateways, performs auto-scaling and one-click software updates with no downtime (blue/green). You don’t need to do anything!
- Built-in Protections
As long as you have configured intrusion prevention (IPS) (via inspection with built-in TLS decrypt) you automatically have built-in protections. Valtix Gateways protect your public cloud deployments for (a) Internet-facing attacks (ingress), (b) stopping east-west lateral movement of attacks, and (c) preventing exfiltration on outbound attacks. Customers can choose to deploy updates the same day as the signatures are available or delay them (perhaps after testing them on a test env).
- Built-in Threat Research
The Threat Research feature allows you to search any given attack, CVE, or IPS rule id. This becomes invaluable to conduct research and decide which IPS profiles to enable.
- Block the Bad Stuff – including encrypted flows
Since the traffic is inspected (both encrypted, with options for reverse proxy, or forward proxy and, unencrypted with forwarding) by Valtix Gateways… there’s nothing to do.
Recommendations
So what does Valtix recommend and provide?
-
- Don’t leave your doors open – don’t leave your Azure Network Security Groups (NSGs) wide open to the Internet, especially for something as sensitive as management systems. But also consider how east-west NSGs are set up between VNETs and on-premise.
- Get Visibility – IaaS, PaaS… see all the traffic to/from your applications and outbound to the Internet. Use the out-of-band traffic data (DNS queries, VPC/VNET flow logs) and inline inspection to get an overview. Which instances and VPCs are connecting to malicious sites?
- Protect all traffic – Implement inline inspection of all traffic (encrypted and unencrypted) proactively (a) enforce workload segmentation and access control on who can talk to whom, (b) block malicious traffic, (c) stop outbound connections to unapproved sites using an allow/block list with FQDN and URL filtering categories. You don’t need another alert to say a production instance connected to a phishing site.
- Build context-sensitive policies – Turning visibility into enforcement of controls is not easy if you’re creating broad-stroke security policies. Leveraging continuous cloud asset discovery of an elastic environment with traffic visibility and threat intelligence allows you to create dynamic multi-cloud and multi-account policies. This uses cloud asset tags to create policies instead of static IPs which have no meaning in the cloud from a security perspective.
- Treat PaaS as an east-west story – for too long we’ve assumed that the PaaS itself is secure; don’t trust them, verify. Valtix brings visibility and control of PaaS in one place.
Final Thoughts
This is not the first attack on cloud infrastructure and not the last misconfiguration of a cloud storage bucket, a few examples:
- Azurescape – Azure Container Instances (ACI) can be compromised to allow an attacker to gain full control over other containers.
- ChaosDB – a now-fixed Azure Cosmos database vulnerability that attackers could use to gain full admin access to other customers’ database instances without any authorization.
- OMIGOD – attackers exploiting the open management infrastructure (OMI) agent installed in Azure Linux machines.
The security model for all major public clouds is built on the shared security model:
- Public cloud providers: own the responsibility to secure their core infrastructure commonly called infrastructure-as-a-service (IaaS).
- Customer: uses the cloud’s settings to configure their IaaS and PaaS securely, and also deploys security for their applications that use these.
Indicators of the Problem aka the Smoke
This is not an issue for a single public cloud – sooner or later it will affect others. A few things clearly noticeable in today’s public cloud environment:
- Depending on the cloud provider alone to secure the PaaS infrastructure.
- Relying only on the cloud security posture management (CSPM) tools has created a false sense of comfort.
- The continuous pace of innovation and competition resulting in new cloud services being launched every week, perhaps with inadequate threat modeling.
The Fire
The primary reason for these issues is that the race for digital transformation and agility has made us drink the Kool-Aid of public cloud proponents and assume that the cloud is inherently secure. We forgot some of the most basic principles of security:
- Trust but verify – Is the cloud provider truly the best protector, and how do you confirm that?
- You can’t protect what you can’t see aka get visibility – Each cloud provider has 5 different places to look at for logs and metrics of your cloud services, but is there one place to get visibility of the actual traffic flows? Meta-data about API calls are nice, but is there an attacker or malicious insider doing exfiltration of sensitive data?
- Defense in depth – No one control is foolproof, and you want to avoid a single point of failure. Without overlapping controls, we’re all vulnerable.
These steps provide a defense-in-depth approach that aligns with the NIST Zero Trust Architecture.
To learn more:
- Try the click-by-click product tour that shows you how Valtix actually does this. You don’t need to actually deploy anything during this tour.
- Watch a 5-minute video that demonstrates this in a demo.
- Talk to our solution architects or get a FREE TRIAL to learn more.
