All Your DNS Records Point to Us

Abstract

In a dangling DNS record (Dare), the resources pointed to by the DNS record are invalid, but the record itself has not yet been purged from DNS. In this paper, we shed light on a largely overlooked threat in DNS posed by dangling DNS records. Our work reveals that Dare can be easily manipulated by adversaries for domain hijacking. In particular, we identify three attack vectors that an adversary can harness to exploit Dares. In a large-scale measurement study, we uncover 467 exploitable Dares in 277 Alexa top 10,000 domains and 52 edu zones, showing that Dare is a real, prevalent threat. By exploiting these Dares, an adversary can take full control of the (sub)domains and can even have them signed with a Certificate Authority (CA). It is evident that the underlying cause of exploitable Dares is the lack of authenticity checking for the resources to which that DNS record points. We then propose three defense mechanisms to effectively mitigate Dares with little human effort.

When Parents and Children Disagree: Diving into DNS Delegation Inconsistency

“…Liu et al show that dangling delegation records referring to expired resources (e.g., cloud IP addresses or names) left in the parent or child pose a significant risk [11]. An attacker can obtain control of these records through the same cloud services by randomly registering new services, and in this way take control of the domain.…”

“…According to RFC2181 resolvers may prefer this information over the delegation provided by the parent. Indeed, in rounds [1][2][3][4][5][6][7][8][9][10][11] we see traffic also going to the child name servers. However, not all traffic goes to servers in the child NSSet, because not all resolvers trust data from the "authority section" due to mitigations against the so-called Kaminsky attack [8].…”

SPWalk: Similar Property Oriented Feature Learning for Phishing Detection

“…Without an explicit comparison between the current webpage and its phishing target, such methods utilize the extracted features to build a binary classifier. The features can be computed from the webpage URL [1]- [6], HTML content [7], queries to remote servers [8], [9], and even publicly-available blacklisting services [10]. However, the attackers have the potential to infer relevant information about the classifier rules.…”

“…According to the URL specification [37], 1 we divide a collection of URLs into three collections of URL segments: domain, directory, and file. For example, a given URL ''https://www.airport-information.com/website/ index.php/en/reference-list'' is divided into three segments: domain segment ''www.airport-information.com'', directory segment ''website/index.php/en'', and file segment ''reference-list''.…”

“…Similarly, the legitimate probability is w w , with w denoting the number of the legitimate URL patterns covering the URL. We calculate the malicious probability ratio to assign URL quality score φ to each node, i.e., φ = m m w w (1) Notice that higher malicious probability and lower legitimate probability produce a higher value of URL quality score. The higher score indicates that the URL is more likely to be malicious.…”