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).
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
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 184.108.40.206 Specific domain IP .fbi.gov with 220.127.116.11 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
Both IPs must be at the same system to let
dns2proxy.py configurate the forwarding
Traditional DNS Spoof adding to the response the original IP address. Using
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 18.104.22.168 .fbi.gov 22.214.171.124 .one.com 127.0.0.1 root@kali:~/dns2proxy#
nospoof.cfg will no be spoofed.
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
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: 126.96.36.199
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: 188.8.131.52 Name: wwww.yahoo.com Address: 184.108.40.206
domains.cfg (or dominios.cfg): resolve all hosts for the listed domains with the listed IP
Ex: .facebook.com 220.127.116.11 .fbi.gov 18.104.22.168
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.
nospoofto.cfg : Don’t send fake responses to the IPs listed there.
Ex: 127.0.0.1 22.214.171.124
victims.cfg : If not empty, only send fake responses to these IP addresses.
Ex: 126.96.36.199 188.8.131.52
resolv.conf : DNS server to forward the queries.
Ex: nameserver 184.108.40.206
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]