This change adds two new Rex exceptions and changes the local comm to raise the right one depending on the circumstances. The problem with the existing model is
that failed binds and failed connections both raised the same exception. This change is backwards compatible with modules that rescue Rex::AddressInUse in additi
on to Rex::ConnectionError. There were two corner cases that rescued Rex::AddressInUse specifically:
1. The 'r'-services mixin and modules caught the old exception when handling bind errors. These have been updated to use BindFailed
2. The meterpreter client had a catch for the old exception when the socket reports a bad destination (usually a network connection dropped). This has been updat
ed to use InvalidDestination as that was the intention prior to this change.
Since AddressInUse was part of ConnectionError, modules and mixins which caught both in the same rescue have been updated to just catch ConnectionError.
msf auxiliary(tnspoison_checker) > show options
Module options (auxiliary/scanner/oracle/tnspoison_checker1):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS 172.16.2.100, 172.16.2.24, 172.16.2.101 yes The target address range or CIDR identifier
RPORT 1521 yes The target port
THREADS 1 yes The number of concurrent threads
msf auxiliary(tnspoison_checker) > exploit
[+] 172.16.2.100:1521 is vulnerable
[*] Scanned 1 of 3 hosts (033% complete)
[-] 172.16.2.24:1521 is not vulnerable
[*] Scanned 2 of 3 hosts (066% complete)
[-] 172.16.2.101:1521 unable to connect to the server
[*] Scanned 3 of 3 hosts (100% complete)
[*] Auxiliary module execution completed
In the reported case, the expected cookies were not present on the
response, thus, the second split was trying to split a `nil`. This
solves the immediately problem by a) splitting up the splits into
discrete sections, and b) `NilClass#to_s`'ing the result of the first
split.
This makes the split safe. Now, there may be a larger issue here where
you're not getting the expected cookies -- it sounds like the target in
this case is responding differently, which implies that the module isn't
going to be effective against that particular target. But, at least it
won't crash. It may merely try fruitlessly the entire run, though. I
can't know without looking at a pcap, and in the reported case, a pcap
seems unlikely since this was a bug found in the field.
This commit contains three fixes as requested on PR
#4003. Those include:
+ Removing extraneous puts statement
+ Checking for valid response
+ SSL support.
William Vu
Jon Hart
Tod Beardsley
HD Moore
Nikita
sinn3r
James Lee
nstarke