Biblio

Infrastructure-as-a-Service (IaaS), more generally the "cloud," changed the landscape of system operations on the Internet. Clouds' elasticity allow operators to rapidly allocate and use resources as needed, from virtual machines, to storage, to IP addresses, which is what made clouds popular. We show that the dynamic component paired with developments in trust-based ecosystems (e.g., TLS certificates) creates so far unknown attacks. We demonstrate that it is practical to allocate IP addresses to which stale DNS records point. Considering the ubiquity of domain validation in trust ecosystems, like TLS, an attacker can then obtain a valid and trusted certificate. The attacker can then impersonate the service, exploit residual trust for phishing, or might even distribute malicious code. Even worse, an aggressive attacker could succeed in less than 70 seconds, well below common time-to-live (TTL) for DNS. In turn, she could exploit normal service migrations to obtain a valid certificate, and, worse, she might not be bound by DNS records being (temporarily) stale. We introduce a new authentication method for trust-based domain validation, like IETF's automated certificate management environment (ACME), that mitigates staleness issues without incurring additional certificate requester effort by incorporating the existing trust of a name into the validation process. Based on previously published work [1]. [1] Kevin Borgolte, Tobias Fiebig, Shuang Hao, Christopher Kruegel, Giovanni Vigna. February 2018. Cloud Strife: Mitigating the Security Risks of Domain-Validated Certificates. In Proceedings of the 25th Network and Distributed Systems Security Symposium (NDSS '18). Internet Society (ISOC). DOI: 10.14722/ndss.2018.23327. URL: https://doi.org/10.14722/nd

Security research has made extensive use of exhaustive Internet-wide scans over the recent years, as they can provide significant insights into the overall state of security of the Internet, and ZMap made scanning the entire IPv4 address space practical. However, the IPv4 address space is exhausted, and a switch to IPv6, the only accepted long-term solution, is inevitable. In turn, to better understand the security of devices connected to the Internet, including in particular Internet of Things devices, it is imperative to include IPv6 addresses in security evaluations and scans. Unfortunately, it is practically infeasible to iterate through the entire IPv6 address space, as it is 2ˆ96 times larger than the IPv4 address space. Therefore, enumeration of active hosts prior to scanning is necessary. Without it, we will be unable to investigate the overall security of Internet-connected devices in the future. In this paper, we introduce a novel technique to enumerate an active part of the IPv6 address space by walking DNSSEC-signed IPv6 reverse zones. Subsequently, by scanning the enumerated addresses, we uncover significant security problems: the exposure of sensitive data, and incorrectly controlled access to hosts, such as access to routing infrastructure via administrative interfaces, all of which were accessible via IPv6. Furthermore, from our analysis of the differences between accessing dual-stack hosts via IPv6 and IPv4, we hypothesize that the root cause is that machines automatically and by default take on globally routable IPv6 addresses. This is a practice that the affected system administrators appear unaware of, as the respective services are almost always properly protected from unauthorized access via IPv4. Our findings indicate (i) that enumerating active IPv6 hosts is practical without a preferential network position contrary to common belief, (ii) that the security of active IPv6 hosts is currently still lagging behind the security state of IPv4 hosts, and (iii) that unintended IPv6 connectivity is a major security issue for unaware system administrators.

Virtual switches are a crucial component of SDN-based cloud systems, enabling the interconnection of virtual machines in a flexible and "software-defined" manner. This paper raises the alarm on the security implications of virtual switches. In particular, we show that virtual switches not only increase the attack surface of the cloud, but virtual switch vulnerabilities can also lead to attacks of much higher impact compared to traditional switches. We present a systematic security analysis and identify four design decisions which introduce vulnerabilities. Our findings motivate us to revisit existing threat models for SDN-based cloud setups, and introduce a new attacker model for SDN-based cloud systems using virtual switches. We demonstrate the practical relevance of our analysis using a case study with Open vSwitch and OpenStack. Employing a fuzzing methodology, we find several exploitable vulnerabilities in Open vSwitch. Using just one vulnerability we were able to create a worm that can compromise hundreds of servers in a matter of minutes. Our findings are applicable beyond virtual switches: NFV and high-performance fast path implementations face similar issues. This paper also studies various mitigation techniques and discusses how to redesign virtual switches for their integration.