David Sopas – Web Security Researcher

Interesting Readings

05/08/16 Advisories , Bug Bounty , Interesting Readings

Latest work done

Latest work done

Just to give a small update on my work… I’ve been more active on my Twitter account so follow me to get the latest updates on my security work 🙂

Also here are some work I’ve done:

Regarding conferences I’ve been on Join 2016 @Braga presenting the talk “Hacking from Black to White”.

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
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
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]

0 likes no responses
23/10/15 Interesting Readings # ,

Hack.lu 2015 slides download

Hack.lu 2015 slides download

Slides from Hack.lu can now be downloaded at http://2015.hack.lu/archive/2015/
Enjoy!

0 likes no responses
21/10/15 Interesting Readings # , ,

Attacking Ruby on Rails

Attacking Ruby on Rails

I want to share a interesting reading that I noticed when searching Mr. G for Ruby security.
I still didn’t finished reading it because lack of time but this weekend this will be on my to-do list.

Paper: http://phrack.org/papers/attacking_ruby_on_rails.html

0 likes no responses
29/09/15 Interesting Readings # , ,

Bug Hunter Appreciation Programs

Interesting reading about security bug bounty written by Eduardo Vela – http://sirdarckcat.blogspot.pt/2015/09/not-about-money.html

You got to love this part:

It is my view, that we shouldn’t call them “Bug Bounty Programs”, I would like them to be called “Bug Hunter Appreciation Programs”. I don’t like the term “Bug Bounty”, because bounty sounds a lot like it’s money up for grabs, when the attitude is that of a gift, or a “thank you, you are awesome”.

0 likes no responses
25/09/15 Interesting Readings , Tips and Tricks # , , , , ,

Yahoo! and other sites vulnerable to Open Redirect

Yahoo! and other sites vulnerable to Open Redirect

A couple of portuguese security researchers published a article about a vulnerability on Linkedin and Yahoo! that allows a malicious user to redirect victims to other sites. The problem is/was located on a vulnerable version of Express – Node.js web application framework.

So with a simple modification in the URL you get a Open Redirect attack:

https://touch.www.linkedin.com////www.google.com/%2e%2e

http://developer.yahoo.com////www.google.com/%2e%2e

http://publish.yahoo.com//www.google.com/%2e%2e

Both Yahoo! attacks are still open to attack and working in Firefox and Opera browsers.

I found out that many other sites are vulnerable to this attack including MySpace. Just searching on the official ExpressJS site you can get a list of big companies and start-ups vulnerable to this attack – http://expressjs.com/resources/applications.html

This is a easy fix – just update your Express Framework and you’re done!

0 likes one response
1 2 3