fdobrovolny
commented
8 months ago Assumptions:
- The customer workloads are not executed within SGX or equivalent secure enclaves.
- The CSP OpenStack administrators are deemed trustworthy since they possess root access to the nodes, enabling them to bypass any form of encryption.
- A third party manages network communication among nodes within a colocation setting or by an independent team, which are both considered unreliable.
Man in the middle Attack
Considering the stated assumptions and the objective to enforce end-to-end (E2E) encryption for user workloads, our primary security concern is averting man-in-the-middle (MITM) attacks. These can be categorized into two distinct forms: active and passive.
Passive Attacks - Eavesdropping
Consider the scenario where an unauthorized individual engages in covert surveillance, such as a rogue network administrator or an intruder with physical access to the data center. I described this type of Attack as 'passive' because their primary action is silently monitoring unencrypted traffic without interfering with data integrity or network operations.
Wiretapping is a common technique employed in such espionage. It involves the unauthorized attachment to network cabling, enabling the covert observation of data transit. This activity typically goes unnoticed as it does not disrupt the flow of network traffic, although it may occasionally introduce minor transmission errors.
https://hackinglab.cz/en/blog/wiretapping/
An alternative strategy involves deploying an interception device that captures and retransmits data, which could introduce network latency or, if deployed disruptively, cause connectivity interruptions. Such devices can be concealed by synchronizing their installation with network downtime, maintenance periods, or less conspicuous times like power outages. They could also be strategically placed in less secure, more accessible locations, such as inter-building network links. This applies to wiretapping as well.
Furthermore, the vulnerability extends to network devices, where an attacker could exploit unsecured management ports or leverage compromised remote management tools (like IPMI) to gain unauthorized access. Such access points, especially those not routinely monitored like backup VPNs, present additional security risks.
Below is a conceptual diagram depicting potential vulnerabilities in an OpenStack deployment across dual regions, highlighting how these passive eavesdropping techniques could be facilitated.
Active - Spoofing / Tampering
Active network attacks like spoofing and tampering exploit various access points, often leveraging vulnerabilities uncovered during passive eavesdropping phases. These attacks actively manipulate or introduce unauthorized communications on the network.
Spoofing involves an attacker masquerading as another device or user within the network. This deception can manifest in several ways:
- ARP Spoofing: The attacker sends forged ARP (Address Resolution Protocol) messages onto the network. This can redirect network traffic flow to the attacker's machine, intercepting, modifying, or blocking data before it reaches its intended destination.
- DNS Spoofing: By responding with falsified DNS replies, an attacker can reroute traffic to malicious sites, further compromising or data exfiltration. This manipulation can divert network traffic from its intended endpoint, potentially redirecting outbound traffic to external malicious sites if network policies do not constrain.
- IP Spoofing: The attacker disguises their network identity by falsifying IP address information in packets, tricking the network into accepting them as legitimate traffic. This can be particularly damaging if encryption is not enforced, enabling the attacker to interact with databases, invoke APIs, or execute unauthorized commands while appearing as a trusted entity.
Moreover, when an active interception device is in place, attackers can extend their capabilities to traffic filtering. They might selectively delete or alter logs and metrics to erase traces of their intrusion or fabricate system performance data, thus obscuring the true nature of their activities. For instance:
- Log Filtering: The attacker can configure the interception device to selectively remove log entries that record their unauthorized activities, effectively erasing evidence of their presence and actions.
- Metric Spoofing: By tampering with or fabricating the system's metrics, attackers can mask the resource utilization spikes or network anomalies typically indicative of a breach, allowing them to maintain persistence within the network undetected.
Below is a conceptual diagram depicting potential vulnerabilities in an OpenStack deployment across dual regions, highlighting how these spoofing attacks could be facilitated.
Notes from the IaaS Team presentation
- IP spoofing from VMs is normally prevented by OpenStack (port security: allowed address pairs)
- https://superuser.openinfra.dev/articles/managing-port-level-security-openstack/
- https://docs.openstack.org/security-guide/networking/services-security-best-practices.html
- (Needs update,
policy.jsonis no longer)
- (Needs update,
- May not be secure enough for L2 networking
- General observation: Somewhere the keys for en/decryption are handled, if the attack happens there, encryption does obviously not help. Threat modeling thus highly desirable.
- When looking at inter-cloud connections, the traffic invariably will go via untrusted cables.
- Encryption in the infra will allow users not to need to know about the details on where infra is located.
- Performance impact: May need opt-out for local trusted scenarios?
- Key management for cross-provider scenarios will be complex -> backlog for now. Begin with encryption OpenStack first
- Talk to Tellus project regarding non-OpenStack implementations
- Exposing infra encryption capability to containers (so we do not end up encrypting twice)
- Discoverability thing
- External (non-SCS :-)) cloud providers may not be trusted
- Exposing infra encryption capability to containers (so we do not end up encrypting twice)
As an SCS Contributor, I want to model possible threats that could be mitigated by E2E encryption so that we can implement encryption in a way that makes sense and serves a purpose.
As arose from the IaaS meeting:
Definition of Ready:
Definition of Done: