Wednesday, December 10, 2014

AliExpress XSS vulnerability - take over any seller account

In this blog post I will discuss a XSS vulnerability I’ve found in AliExpress website.
I discovered this vulnerability while i bought items in the website, i wanted to contact with the seller so i sent him a message. As an application security expert i suspected that the messages system might be vulnerable to XSS so i started investigate it.
after a full investigation i found that it is possible to inject HTML <b> tag into the message, and it will be rendered as HTML code in the recipients' browser.
By injection the following malicious script payload in a message content parameter, the seller will browse to the message center in AliExpress website, thus, the malicious script will be executed on his browser:

Hello Seller :)<b style="position:fixed;top:0;left:0;display:block;width:100%;height:100%" onmouseover="alert('Barak Tawily, AppSec Labs')">PoC</b>

Note: the system doesn't allow send HTML tags in the content of the message, but it allows <b> tag only, thats why the payload to exploit the vulnerability is <b> tag and not any other.



The vulnerability allows the attacker to execute malicious code on the seller's browser, thereby putting in danger all of the AliExpress sellers.

The attack scenario:
1. An attacker sends a message to a store via the "contact now" feature.
2. The attacker sends a malicious script injected inside the message content.
3. The seller browses to the AliExpress message center.
4. The malicious script executed on the seller's browser, which can be lead to several attacks such as perform actions on behalf of a seller, phishing attacks, steal the victim's sessions identifier, etc.
5. The attacker succeeds in executing malicious code in the seller's browser and will take it over on his store.

Skilled hacker might exploit this vulnerability and perform ranged attack by sending malicious messages to all AliExpress sellers and will cause a huge damage to AliExpress website.

A Proof of Concept (PoC) video can be found at the following link:
https://www.youtube.com/watch?v=78Y0CEQYN1Q

Wednesday, January 15, 2014

SoapUI Code Execution Vulnerability - CVE-2014-1202

In this blog post I will discuss a vulnerability I’ve found in the SoapUI product before version 4.6.4 (CVE-2014-1202).
I discovered this vulnerability during a penetration test in which I saw that the SoapUI software allows the clients to execute a Java code on the local machine by putting a Java code inside the following tag:

${=JAVA CODE};

The vulnerability allows the attacker to execute the java code on the victim's machine, thereby putting in danger the SoapUI users, including developers, penetration testers, etc.

The SoapUI product allows users to open a SOAP / REST project and import  WSDL/WADL files that help the users to communicate with the remote server easily.
WSDL/WADL files are XML-based grammar that define the operations that a web service offers and the format of the request and response messages that the client sends to and receives from the operations.
In WSDL/WADL files, the file owner can determine the default values of some parameters. Thus, an attacker can impersonate a legitimate web service and inject a malicious Java code into a default value of one of the parameters, and spread it to SoapUI clients.
When a SoapUI client will load a malicious WSDL/WADL file to his project in the SoapUI software, and send a request containing the malicious Java code, the SoapUI will execute the malicious Java code on the victim's computer.

The attack scenario:
1. An attacker impersonates a regular web service with a malicious WSDL containing the malicious Java code.
2. The victim creates a new project in the SoapUI and loads the malicious WSDL.
3. The victim decides to send a request to the remote server, thus, the SoapUI executes the malicious Java code.
4. The attacker succeeds in executing malicious code in the victim's machine and will take it over.

A Proof of Concept (PoC) video can be found at the following link:
                    
An example of a malicious WSDL file can be found at the following link: