Skip to content

Latest commit

 

History

History
98 lines (70 loc) · 6.83 KB

README.md

File metadata and controls

98 lines (70 loc) · 6.83 KB
Raw

Kaminsky exploit

Tool to exploit the Kaminsky DNS vulnerability

This tool is an implementation of the vulerability that Dan Kaminsky exposed in 2008. In its current form it works only with IPv4 addresses.

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

In order for this tool to be executable on your machine, you need to have the following installed:

Installing

Simply clone the code from the GitHub repository.

The example is shown in Git Bash:

  1. Open Git Bash

  2. Navigate to the directory where you want to store the project. You can do that with the following command:

$ cd /path/to/directory

Note that if the path has whitespaces in it, you need to encapsulate it in quotes(").

  1. Clone the respository. You can do that by executing the following command in Git Bash:
$ git clone ${REPOSITORY_URL}

You can find the respository URL on the GitHub page.

Usage

To execute the exploit navigate to the directory where the scripts are located and execute the following command:

python kamins.py victimIP targetZone yourNameserverIP [-t/--ttl ttl] [-s/--silent -l/--loud] [-d authoritativeNameserverIP]

Arguments without the dash (-) in front of them are positional, meaning that they are required and need to be positioned exactly in the ordering described above. Arguments with a dash (-) in front of them are optional and may be ordered in any way desired, as long as they are after the positional arguments. Each of the given arguments is described below:

  • victimIP - this argument represents the IP of the victim nameserver, whose cache is supposed to be poisoned after attack execution.
  • targetZone - this arguments represents the zone that is going to be spoofed after the attack is executed.
  • yourNameserverIP - this argument represents the IP of the nameserver that the attacker wishes to become authoritative for the target zone, with respect to the victim.
  • -t/--ttl ttl - the value after the positional argument is going to be the Time-To-Live of the record in the victims cache.
  • -s/--silent - this argument speci es that the attacker wishes to execute the silent variant of the attack. If neither this nor the following argument are provided, silent method will be executed by default.
  • -l/--loud - this argument speci es that the attacker wishes to execute the loud variant of the attack. It is important to note this argument are the one described above are exclusive, meaning that at most one can be provided.
  • -d authoritativeNameserverIP - this is the IP of the authoritative nameserver used in the demo. It is needed because normal NS record lookup for the target zone won't provide this IP, as the demo is executed in a closed environment.

Description of the attack

The attack that this script performs is called DNS-cache poisoning. There exists multiple versions of this attack, but we are speci cally carrying out an attack that is using the Kaminsky Vulnerability found by Dan Kaminsky in the summer of 2008. What we do in this attack is fake a response of an authoritative DNS-server to make it cache an NS-record (authoritative domain) of our choice linked to an A-record of our choice (IP-address). The fake response has to meet the following requirements:

  1. It should have the same question as the original query of the recursive DNS to the authoritative DNS.
  2. It should have the destination port set to the source port of the original query of the recursive DNS to the authoritative DNS.
  3. It should have the same query-id as the original query of the recursive DNS to the authoritative DNS.
  4. It should be an authoritative response.
  5. It should arrive before the actual response.

Meeting requirements 1, 4, and 5 is not so hard as we know the question (we sent it), making an answer authoritative only requires you to IP a bit, and we answer instantly without any calculations so our fake response will most likely arrive before the actual response. Meeting requirements 2 and 3 is harder as the query-id has 2^16 possible values and the port has 2^11 possible values, leaving 2^27 possible combinations. We implemented 2 different methods to deal with these problems. The 1st implementation, the 'loud' implementation, just tries to guess the query-id. The second implementation, the 'silent' implementation, ARP-spoofs the recursive DNS server and the authoritative DNS server (assuming they are in the same network) and simply reads the traffic in between these servers making it trivial to answer a correctly formed response.

Given that:

  • the victim DNS's IP-address is a
  • our IP-address is b
  • the zone we are trying to spoof is z
  • the IP-address we want to put in the victim's cache for zone z is c

Loud method

  1. find out the IP-addresses of the servers that are authoritative for zone c and put it in a list l
  2. send a DNS-query to a asking where is 'somerandomstring'.z
  3. we know now that a is going to ask some server(s) of l where 'somerandomstring'.z is with some query-id q, so we answer (with the same question, a random query-id and the authoritative bit set to 1) that we do not know where 'somerandomstring'.z is but you can ask any of the following servers: all servers in l with in the glue length(l) times the IP of c
  4. Now we ask a for the NS-record of any of the servers in l if it responds c we were successful in guessing the query-id, if it answers something else we return to step 2

Silent method

  1. nd out the IP-addresses of the servers that are authoritative for zone c and put it in a list l
  2. we ARP-spoof all addresses in l to a with b's MAC-address
  3. send a DNS-query to a asking where is 'somerandomstring'.z
  4. we know now that a is going to ask some server(s) of l where 'somerandomstring'.z is with some query-id q, but it will actually ask us (ARP-spoofed)
  5. we read the packet and send back an authoritative answer pretending to be the same server a contacted with query-id q saying we do not know where 'somerandomstring'.z is but ask c who is authoritative for z
  6. a now thinks c is authoritative for z and it will put it in cache as we sent an authoritative answer
  7. if this was successful, a will now ask c where is 'somerandomstring'.z

Authors

See also the list of contributors who participated in this project.

License

This project is licensed under the MIT License.