Last updated at Wed, 26 Jul 2017 16:38:40 GMT
The bailiwicked modules (host and domain) were updated today to include the ability to predict the time window between the outgoing request from the target nameserver and the response from the real nameserver(s). This measurement is used to tune the number of spoofed replies sent by the exploit. The result is a big increase in exploit reliability, especially when the target domain has a ton of nameservers (Yahoo has eight) or changes its responsiveness during the test (BIND tends to slow down when it has a full cache). The new self-tuning code is activated with the XIDS option is set to '0', which is now the default. FreeBSD and Mac OS X support are still in the works, but should be functional sometime this weekend. The timing analysis feature can also be access through a new command ('racer'). In the examples below, the first command tests the timing between the nameserver at 192.168.0.2 and the metasploit.com DNS servers. The second command tests the timing between the nameserver 4.2.2.3 (a public DNS server) and the metasploit.com DNS servers. You can see by the results that the timing differences are significant:
msf auxiliary(bailiwicked_host) > racer 192.168.0.2 metasploit.com
[*] race calc: 50 queries | min/max/avg time: 0.05/0.23/0.09 | min/max/avg replies: 6/121/49
msf auxiliary(bailiwicked_host) > racer 4.2.2.3 metasploit.com
[*] race calc: 50 queries | min/max/avg time: 0.02/0.17/0.05 | min/max/avg replies: 1/29/6
In the first case (192.168.0.2), the average number of queries we can send before the real server replies is around 49, which means about 80 fake responses. In the second example, the average is only 6, which means about 12 fake responses. To be conservative, these modules take the average, multiple it by 1.5, then divide it by the number of nameservers. This leads to a fairly accurate timing estimate and quicker attacks.
