Haya Shulman

Security of Patched DNS

Most caching DNS resolvers still rely for their security, against poisoning, on validating that the DNS responses contain some ‘unpredictable’ values, copied from the request. These values include the 16 bit identifier field, and other fields, randomised and validated by different ‘patches’ to DNS. We investigate the prominent patches, and show how attackers can circumvent all of them, namely:

Vulnerable Delegation of DNS Resolution

A growing number of networks delegate their DNS resolution to trusted upstream resolvers. The communication to and from the upstream resolver is invisible to off-path attackers. Hence, such delegation is considered to improve the resilience of the resolvers to cache-poisoning and DoS attacks, and also to provide other security, performance, reliability and management advantages.

Socket overloading for fun and cache-poisoning

We present a new technique, which we call socket overloading, that we apply for off-path attacks on DNS. Socket overloading consists of short, low-rate, bursts of inbound packets, sent by off-path attacker to a victim host. Socket overloading exploits the priority assigned by the kernel to hardware interrupts, and enables an off-path attacker to illicit a side-channel on client hosts, which can be applied to circumvent source port and name server randomisation. Both port and name server randomisation are popular and standardised defenses, recommended in [RFC5452], against attacks by off-path adversaries. We show how to apply socket overloading for DNS cache poisoning and name server pinning against popular systems that support algorithms recommended in [RFC6056] and [RFC4097] respectively. Our socket overloading technique may be of independent interest, and can be applied against other protocols for different attacks.

Cloudoscopy: services discovery and topology mapping

We define and study cloudoscopy, i.e., exposing sensitive information about the location of (victim) cloud services and/or about the internal organisation of the cloud network, in spite of location-hiding efforts by cloud providers. A typical cloudoscopy attack is composed of a number of steps: first expose the internal IP address of a victim instance, then measure its hop-count distance from adversarial cloud instances, and finally test to find a specific instance which is close enough to the victim (e.g., co-resident) to allow (denial of service or side-channel) attacks. We refer to the three steps/modules involved in such cloudoscopy attack by the terms IP address deanonymisation, hop-count measuring, and co-residence testing. We present specific methods for these three cloudoscopy modules, and report on results of our experimental validation on popular cloud platform providers. Our techniques can be used for attacking (victim) servers, as well as for benign goals, e.g., optimisation of instances placement and communication, or comparing clouds and validating cloud-provider placement guarantees.

Retrofitting Security into Network Protocols: The Case of DNSSEC

DNS Security Extensions (DNSSEC) became standardized more than 15 years ago, but its adoption is still limited. The recent publication of several new, off-path DNS cache-poisoning and wide-scale man-in-the-middle attacks should motivate DNSSEC adoption. However, significant challenges and pitfalls have resulted in severely limited deployment, which is furthermore often incorrect (and hence vulnerable). The authors outline these problems and suggest directions for improvement and further research.

DNSSEC: Security and availability challenges

DNSSEC was proposed more than 15 years ago but its (correct) adoption is still very limited. Recent cache poisoning attacks motivate deployment of DNSSEC. In this work we present a comprehensive overview of challenges and potential pitfalls of DNSSEC, including: Vulnerable configurations: we show that inter-domain referrals (via NS, MX and CNAME records) present a challenge for DNSSEC deployment and may result in vulnerable configurations. Due to the limited deployment so far, these configurations are expected to be popular. Incremental Deployment: we discuss implications of interoperability problems on DNSSEC validation by resolvers and potential for increased vulnerability due to popular practices of incremental deployment. Super-sized Response Challenges: we explain how large DNSSEC-enabled DNS responses cause interoperability challenges, and can be abused for DoS and even DNS poisoning.

Fragmentation Considered Leaking: Port Inference for DNS Poisoning

Internet systems and networks have a long history of attacks by off-path adversaries. An off-path adversary cannot see the traffic exchanged by the legitimate end points, and in the course of an attack it attempts to impersonate some victim by injecting spoofed packets into the communication flow. Such attacks subvert the correctness and availability of Internet services and, among others, were applied for DNS cache poisoning, TCP injections, reflection DDoS attacks.

DNS authentication as a service: preventing amplification attacks

We present the first defence against DNS-amplification DoS attacks, which is compatible with the common DNS servers configurations and with the (important standard) DNSSEC. We show that the proposed DNS-authentication system is efficient, and effectively prevents DNS-based amplification DoS attacks abusing DNS name servers. We present a game-theoretic model and analysis, predicting a wide-spread adoption of our design, sufficient to reduce the threat of DNS amplification DoS attacks. To further reduce costs and provide additional defences for DNS servers, we show how to deploy our design as a cloud based service.

Ethical considerations when employing fake identities in online social networks for research.

Online social networks (OSNs) have rapidly become a prominent and widely used service, offering a wealth of personal and sensitive information with significant security and privacy implications. Hence, OSNs are also an important—and popular—subject for research. To perform research based on real-life evidence, however, researchers may need to access OSN data, such as texts and files uploaded by users and connections among users. This raises significant ethical problems. Currently, there are no clear ethical guidelines, and researchers may end up (unintentionally) performing ethically questionable research, sometimes even when more ethical research alternatives exist. For example, several studies have employed “fake identities” to collect data from OSNs, but fake identities may be used for attacks and are considered a security issue. Is it legitimate to use fake identities for studying OSNs or for collecting OSN data for research? We present a taxonomy of the ethical challenges facing researchers of OSNs and compare different approaches. We demonstrate how ethical considerations have been taken into account in previous studies that used fake identities. In addition, several possible approaches are offered to reduce or avoid ethical misconducts. We hope this work will stimulate the development and use of ethical practices and methods in the research of online social networks.

Internet-wide study of DNS cache injections

DNS caches are an extremely important tool, providing services for DNS as well as for a multitude of applications, systems and security mechanisms, such as anti-spam defences, routing security (e.g., RPKI), firewalls. Subverting the security of DNS is detrimental to the stability and security of the clients and services, and can facilitate attacks, circumventing even cryptographic mechanisms. We study the caching component of DNS resolution platforms in diverse networks in the Internet, and evaluate injection vulnerabilities allowing cache poisoning attacks. Our evaluation includes networks of leading Internet Service Providers and enterprises, and professionally managed open DNS resolvers. We test injection vulnerabilities against known payloads as well as a new class of indirect attacks that we define in this work. Our Internet evaluation indicates that more than 92% of the Internets DNS resolution platforms are vulnerable to records injection and can be persistently poisoned.