This exploit allows an authenticated user to execute arbitrary code on the IPCop 2.1.9 system. The exploit works by sending a malicious POST request to the email.cgi script, which is used to configure the email settings. The malicious payload is sent in the EMAIL_PW parameter, which is then executed by the system. The exploit requires the attacker to have valid credentials for the system.
Apache OFBiz 17.12.03 contains cross-site scripting and unsafe deserialization vulnerabilities via an XML-RPC request.
This application is prone to a cross-site scripting in the 'searchdata' parameter at the following path: Reflected: http://localhost/admin/search-invoices.php, Reflected: http://localhost/client/search-invoices.php, Stored: http://localhost/client/client-profile.php. Payloads: Reflected: </h4><script>alert(document.cookie)</script>, Stored: "><script>alert(document.cookie)</script>Anuj+Kumar.
The password and connection string for the database are stored in a yml file. To access the yml file you can go to http://<website>/core/config/databases.yml file and download.
A stored XSS vulnerability exists in WordPress Plugin WP Customize Login 1.1, which allows an attacker to inject malicious JavaScript code into the 'Change Logo Title' input field. When the malicious code is triggered, it will execute and display a pop-up with the user's cookie information.
This exploit sends a BXSS payload to the site, waits until the admin fires it, steals the admin's session using the BXSS script, and then uses the admin's session to upload a PHP shell. It then makes a reverse TCP connection.
The application interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. These actions can be exploited to perform authentication detriment and account password change with administrative privileges if a logged-in user visits a malicious web site.
This application is prone to a cross-site scripting in the 'arrival' and 'departure' parameters at the following path: http://localhost/marimar/index.php?p=booking. The payload used is: "></div><script>alert("XSS-MSG")</script>
In older versions of Neo4j, when the shell server is enabled, RCE can be obtained via a Java deserialization exploit. In the ShellServer interface, a method setSessionVariable(Serializable paramSerializable, String paramString, Object paramObject) exists. Neo4j also has a dependency (rhino 1.7.9) with known RCE gadget chains. By crafting an object to abuse these gadget chains, one obtain RCE via the shell server. To create this from scratch using Java, you’ll need to modify the ysoserial library to include the payload found here https://github.com/mozilla/rhino/issues/520 (an update of the existing rhino gadget) as well as modify the ysoserial POM file to include the correct version of rhino. Rebuild ysoserial and include it on your exploit’s classpath. From there, you can use the ShellServer interface and associated code found in neo4j-shell-3.4.18.jar to make your client aware of the server’s method stubs. Now you should be able to call the setSessionVariable method from your exploit/client via RMI. In your exploit, use ysoserial to generate a payload as follows: Object payload = new RhinoGadget().getObject(COMMAND), and then call the setSessionVariable with the payload in the paramObject parameter. The other two parameters can be anything. This will cause the server to deserialize your payload, triggering the gadget chain, and running your command. It is worth noting that we chose to exploit this method and the paramObject parameter as this was the most direct, any method that takes in an Object (other than String or a primitave) is likely vulnerable as well.
An attacker can bypass authentication by entering anything in the username and password fields and then changing the username to 'admin' or '1'='1'#. This will allow the attacker to log in as admin without providing valid credentials.
Services By CQR