Posted on

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.org 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 sourced projects.

Nibble Blog

On 26 November 2016, I downloaded Nibble Blog version 4.0.5 for testing. Soon enough I found an XSS in 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"e="><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 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 both replies from both the 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 for this feature, and it was coded, but it was not merged it 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 by forking from the version with XSS vulnerabilities this 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 the openness of him throughout the process.

For future pentester

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

Categories: All