經過域名的Nameservers劫持域名

看到一篇頗有意思的文章,講述的是若是經過控制一個域名的Nameservers服務來實現必定機率的劫持域名的DNS解析權,下面簡述下筆記。promise

dig查看域名解析記錄

mandatory@script-srchttpsyvgscript ~> dig NS iom.int

; <<>> DiG 9.8.3-P1 <<>> NS iom.int
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9316
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;iom.int.            IN    NS

;; ANSWER SECTION:
iom.int.        86399    IN    NS    ns1.gva.ch.colt.net.
iom.int.        86399    IN    NS    ns1.zrh1.ch.colt.net.

;; Query time: 173 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Dec  8 14:12:47 2016
;; MSG SIZE  rcvd: 81

跟蹤域名解析過程

如上看到的是正常來自8.8.8.8的解析記錄,可是咱們使用dig +trace跟蹤下域名的解析過程就會發現,其實一個域名的解析是經過了不少不一樣的Nameservers服務器的,以下緩存

mandatory@script-srchttpsyvgscript ~> dig iom.int +trace

; <<>> DiG 9.8.3-P1 <<>> iom.int +trace
;; global options: +cmd
.            209756    IN    NS    g.root-servers.net.
.            209756    IN    NS    m.root-servers.net.
.            209756    IN    NS    i.root-servers.net.
.            209756    IN    NS    l.root-servers.net.
.            209756    IN    NS    f.root-servers.net.
.            209756    IN    NS    b.root-servers.net.
.            209756    IN    NS    c.root-servers.net.
.            209756    IN    NS    h.root-servers.net.
.            209756    IN    NS    d.root-servers.net.
.            209756    IN    NS    k.root-servers.net.
.            209756    IN    NS    j.root-servers.net.
.            209756    IN    NS    e.root-servers.net.
.            209756    IN    NS    a.root-servers.net.
;; Received 228 bytes from 172.16.0.1#53(172.16.0.1) in 30 ms

int.            172800    IN    NS    ns.icann.org.
int.            172800    IN    NS    ns1.cs.ucl.ac.uk.
int.            172800    IN    NS    ns.uu.net.
int.            172800    IN    NS    ns0.ja.net.
int.            172800    IN    NS    sec2.authdns.ripe.net.
;; Received 365 bytes from 192.5.5.241#53(192.5.5.241) in 88 ms

iom.int.        86400    IN    NS    ns1.iom.org.ph.
iom.int.        86400    IN    NS    ns2.iom.org.ph.
iom.int.        86400    IN    NS    ns1.gva.ch.colt.net.
iom.int.        86400    IN    NS    ns1.zrh1.ch.colt.net.
;; Received 127 bytes from 128.86.1.20#53(128.86.1.20) in 353 ms

iom.int.        86400    IN    A    54.154.14.101
iom.int.        86400    IN    NS    ns1.zrh1.ch.colt.net.
iom.int.        86400    IN    NS    ns1.gva.ch.colt.net.
;; Received 97 bytes from Cnlouds#53(212.74.78.22) in 172 ms

出現問題

如今就存在這麼一種狀況,這些個不一樣的Nameservers服務中有一個域名已經失效了、已經被註銷了,目標域名解析過程當中,系統並不會告訴你解析過程當中有一個Nameservers服務已經失效,而是一個Nameservers服務查詢不到時就會繼續轉給下一個Nameservers去查詢。bash

由此致使的一個問題是,當失效的那個Nameservers服務域名被惡意註冊的話,就能夠實現劫持目標域名的DNS解析權限。目標域名被咱們控制的Nameservers服務解析的機率50%左右,並且DNS緩存也存在必定的時間限制,能夠經過增長DNS緩存TTL生存時間的生效期解決,而後就能夠作一些流量劫持,DDOS等危害操做。服務器

可能出現的場景

  1. 不少網站中引入了第三方資源,而當第三方資源域名失效且未被註冊時,便可致使網站引入惡意的第三方代碼資源,如XSS代碼竊取用戶cookie/博彩/DDOS等持久化控制。 案例:hackone - twitter
  2. 直接使用dig查詢一個網站的域名解析過程,查看解析過程當中的Nameservers服務域名是否失效且未被註冊(或已被控制),亦可打到目的。

原文

Hijacking Broken Nameservers to Compromise Your Targetcookie

https://thehackerblog.com/respect-my-authority-hijacking-broken-nameservers-to-compromise-your-target/網站

相關文章
相關標籤/搜索