Friday, February 20, 2015

Autorize - automatic authorization enforcement detection extension for Burp Suite


Autorize is an automatic authorization enforcement detection extension for Burp Suite. It was written in Python by Barak Tawily, an application security expert at AppSec Labs. Autorize was designed to help security testers by performing automatic authorization tests.
alt tag


  1. Download Burp Suite (obviously):
  2. Download Jython standalone JAR:
  3. Open burp -> Extender -> Options -> Python Environment -> Select File -> Choose the Jython standalone JAR
  4. Install Autorize from the BApp Store or follow these steps:
  5. Download the file.
  6. Open Burp -> Extender -> Extensions -> Add -> Choose file.
  7. See the Autorize tab and enjoy automatic authorization detection :)

User Guide - How to use?

  1. After installation, the Autorize tab will be added to Burp.
  2. Open the configuration tab (Autorize -> Configuration).
  3. Get your low-privileged user authorization token header (Cookie / Authorization) and copy it into the textbox containing the text "Insert injected header here".
  4. Click on "Intercept is off" to start intercepting the traffic in order to allow Autorize to check for authorization enforcement.
  5. Open a browser and configure the proxy settings so the traffic will be passed to Burp.
  6. Browse to the application you want to test with a high privileged user.
  7. The Autorize table will show you the request's URL and enforcement status.
  8. It is possible to click on a specific URL and see the original/modified request/response in order to investigate the differences.

Authorization Enforcement Status

There are 3 enforcement statuses:
  1. Authorization bypass! - Red color
  2. Authorization enforced! - Green color
  3. Authorization enforced??? (please configure enforcement detector) - Yellow color
The first 2 statuses are clear, so I won’t elaborate on them.
The 3rd status means that Autorize cannot determine if authorization is enforced or not, and so Autorize will ask you to configure a filter in the enforcement detector tab.
The enforcement detector filters will allow Autorize to detect authorization enforcement by fingerprint (string in the message body) or content-length in the server's response.
For example, if there is a request enforcement status that is detected as "Authorization enforced??? (please configure enforcement detector)" it is possible to investigate the modified/original response and see that the modified response body includes the string "You are not authorized to perform action", so you can add a filter with the fingerprint value "You are not authorized to perform action", so Autorize will look for this fingerprint and will automatically detect that authorization is enforced. It is possible to do the same by defining content-length filter.

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:

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:


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: