When To Report a Security Bug

With the rising popularity of bug bounties, I’ve decided to find some bugs online myself. You would be amazed by how vulnerable websites are and how easy it is to find an XSS vulnerability. Try using a simple Google dork like inurl:“.php?id=” and you could definitely find a couple of sites that are vulnerable to XSS.

I had previously hunted for bugs online in hopes of getting some bounties using the openbugbounty platform. In a matter of a few months, I was able to find a little over 1000 XSS. I decided to return to my roots to find XSS in open-source projects.

Nibble Blog

On 26 November 2016, I downloaded Nibble Blog version 4.0.5 for testing. Soon enough I found an XSS on the quote creation page.

The following is the POST request to the server with “quote” as the vulnerable parameter.

POST /nibble/admin.php?controller=post&action=new_quote HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://127.0.0.1/nibble/admin.php?controller=post&action=new_quote
Cookie: SOFTCookies7188_sid=S6kc8ML6xKdrxg37P8tvqPZUXmsmzigS; PHPSESSID=16tcqjfi5plvrt4br3s5u5giv0
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 152

token=f3050b47c15fcc9eb44b0916a1b06f8dac87d124&quote="><img src="/" />&id_cat=0&tags=&slug=&button_add=Publish

Exploring further shows that there is a plugin system in place. Sweet! More parameters to test.

And sure enough, all the default plugins were vulnerable. Here is a table that summarizes all the vulnerable parameters with their respective plugin.

S/N Plugin
Name
Parameter Name(s)
1 All
plugins
title
2 My
image
caption
3 About name,
about*
4 Google
analytics
id
5 Maintenance
Mode
message
6 Sponsors code
7 Tag
cloud
min_size,
max_size
8 Twitter
cards
creator,
site

You can see some broken image tags. Each broken tag represents the failure of encoding or sanitization which allows the payload to be interpreted by the browser.

Now let’s move on to Kopage.

Kopage

I chanced upon the Kopage demo version on 20 December 2016.

It was close to midnight, and I was about to head to bed when I triggered an alert box. I was now pumped and had to do some further testing. I downloaded and installed a local copy (version 3.0.1) and an hour later here is what I found.

There are 3 XSS vulnerabilities in Kopage (or at least those that I could find).

  1. Adding a new subpage
    2. Menu Options
    3. Gallery

What happens after?

I wrote two reports with detailed instructions on replicating the issues and submitted them.

Here are the replies from both owners.

Hi Edric,

I’m checking the exploit, and yes exist, but you need to have access to the admin panel and create a post, anyway, this kind of “vulnerabilities” I think is in all CMS who permit create a post/page, and allow to change the source code of the HTML or I’m wrong ?

-Nibble Blog (29 November 2016)

Edric, thanks for your report. All of these require user to be logged in as admin first, why would website admin want to add any of these to his own website?

-Kopage (21 December 2016)

Noticed what the problem was? These platforms were created for a single user, and therefore the reported vulnerabilities only affect the owner.

Conclusion

Nibble Blog

When I received the message from Nibble Blog, I immediately googled “nibble blog multi-user”.

It turns out, someone had requested this feature, and it was coded, but it was not merged into the main branch it was distributed via Dropbox. The link to the thread is here. The newer version seems to have multi-user capabilities, and therefore forking from the version with XSS vulnerabilities should worry the users.

The owner and developer of Nibble Blog have moved to a new project Bludit which supports multi-user.

Kopage

Simon, the co-founder of Kopage requested for the bugs to be fixed before releasing this post. As of now, all the mentioned bugs are fixed and I appreciate his openness of him throughout the process.

Note to self

In the future, make sure that your proof of concept illustrates how a malicious user would exploit the vulnerability. In my case of XSS, it would mean that I would have to be able to privilege escalate by stealing a cookie or keylogging the admin’s password and not just simply providing screenshots of alert boxes.