Surveying CodeCanyon Scripts – XSS, LFI, SQLi & More

August 2, 2015

Introduction

Have a job for me? Check my about page for contact.

CodeCanyon is a well known marketplace for code such as PHP scripts. I’ve taken a little of my time this week to check through “new” items coming through as well as some popular and random scripts. I decided I would not do an extensive penetration test on each script, simply see how fast I can find a vulnerability from each script. I didn’t take any longer than half an hour on any script I chose to look at. In total I found 17 vulnerabilities, without any use of scanners or any automated tools, this was simply me and the browser.

Looking through Codecanyon’s terms of service and why you should buy from us page, I can see that they do have people review an item for quality ( http://codecanyon.net/buy) and go so far to call them experts. I understand that there are many items that need to be published and that reviewers will be pressured to look through as many as possible within a day, but find it quite worrying for buyers of CodeCanyon that I found 17 vulnerabilities within a few days.

I disclosed the shell uploading vulnerabilities to authors as this could directly affect their server from even the most novice of hacker, the other vulnerabilities were not disclosed due to my lack of time for reporting vulnerabilities, I also didn’t want heated emails back.

Statistics

Some of these vulnerabilities have variations such as authentication which is needed to trigger the vulnerability, but the majority of vulnerabilities needed no authentication or special treatment. One thing I learnt from this is that it’s much easier to do a penetration test with access to the administration panel.

Total Scripts: 15

Total Vulnerabilities: 17

I decided to also make a graphical visualisation of the numbers to break up the text a bit.

aFrom a glance it’s easy to see that XSS is the large portion of the vulnerabilities triggered, all of these XSS vulnerabilities were stored, meaning there were no checks before it went into a database. Many people shrug off XSS vulnerabilities as not being a big deal, but can be quite the opposite. A few examples for XSS is redirecting the admin to infect them, cookie stealing or even redirecting to a phishing page to try and get the login details. I only tested PHP scripts and not other types, such as wordpress plugins, I thought it would be easier to just stick to one category.

Legal

I’m hesitant to link the CodeCanyon scripts because I feel CodeCanyon may get a bit heavy with me, this article isn’t supposed to say CodeCanyon is a terrible marketplace. I’ve seen many items which are quite well made and are impressive, I just feel as if part of the review process must be looked at further, because so many of these applications are vulnerable straight from release.

Vulnerability Overview

The first vulnerability I want to talk about is the script with local file inclusion, I first needed to login to the administration panel to find this vuln, although, to trigger this you do not need authentication whatsoever. Discovering it was as simple as using the Firefox web developer network tool, once logged in as an administrator, Firefox captured a request which had a get parameter set to a Javascript file. I attempted to elevate into directories using the common file name index.php, which if it had a LFI would eventually give me a hit. Luckily for me it did hit and I got the script source code. It was hosted within a folder so attempted to elevate further and got to their root domain source code as well, which seemed to be Joomla.

aThis particular script was designed to be for live chat and could be popular as it is quite unique, a lot of chat services ask for extortionate amounts to have their service and this could be a viable alternative. From what I see in comments there are fairly positive reviews for this particular product and feel I’m one of very few that look first at the security measures of a product before purchase in CodeCanyon.

The next vulnerability was a SQL injection, one of those vulnerabilities you first learn about when coming into security or web developing, so I was quite surprised to find 2 SQLi’s. I understand when it comes to web app development you can have a mammoth task in implementing security in big projects, but SQL injection should almost be defunct. There has been a large span of time where awarness has been raised and theres things like binding parameters which sanatise for you available when doing a database operation, so I don’t get how this is still going on. SQL injection should be like remote file inclusion, long gone.

b

I hadn’t actually tested this with a SQL injection tool like SQLMap or put any commands in I simply just put a single quotation, but from what I can see it’s fairly evident it’s some form of SQL injection. It broke with the single quotation stating a syntax error, that’s enough evidence for me. It was the list parameter in the get request that I tested that broke the application, I’ve put a rectangle around it because there were a fair amount of parameters in this request.

The other SQL injection came authenticated as an administrator so doesn’t have a bigger effect than no authentication. It still is an SQL injection though and shows that some people think it’s ok to leave santisation and filtering out when the user is an administrator because they can be instantly trusted. This is poor system design as their could be a flaw in the login logic, there could be another level, such as moderators in a website which could be hijacked. SQL injection can in some circumstances lead to a hacker uploading a shell to the site and so shouldn’t be taken lightly. This web application was designed for a taxi company.

cInformation disclosure wasn’t as abundant as I thought it would be, only 2 web applications showed signs of information disclosure, although I wasn’t doing a full test so could of been much worse I suppose. The biggest problem I see from modern web applications is using AJAX requests and not giving the correct permissions to the AJAX request pages. Just because it’s only requested in the admin panel doesn’t mean it won’t be found.

In this case this script is designed for a medical practice, holding records of patients, staff and payments coming through. What’s horrifying is that you don’t need any authentication or use SQL injection to get this data from this script, you simply have to call one page.

dThe page is used in the admin panel and is requested with AJAX, the developer did not anticipate that it would be accessed directly and results in sensitive information being shown without any authentication.

The 2nd vulnerability which had information disclosure would show a clients address, email, phone, what they bought and how much in total it all costed. The script was designed as a billing application but the quotes could easily be viewed by anyone. A simple numbering system which increments was used, no random values used whatsoever, allowing anyone to easily enumerate quotes with information.

eThe last information disclosure vuln was interesting, this script was designed as a host panel to show server information, it seemed they had scraped various open source scripts together to make one script. The problem is they didn’t integrate them correctly allowing sensitive information to be shown. They had a script which showed various debugging information, this screenshot shows the XML version but you could also just use the graphical version, there were no restrictions set on this part of the website, the script had simply just redirected to the open source script in this case.

gIt showed a vast amount of information about the current system it was being run on. Noteably the Kernel version, IP address and the amount of free memory. The kernel version could be used to find exploits into this particular system, the IP address could be used to get the real IP of the server (could be using services like Cloudflare) and free memory could help an attacker understand how well an attack is doing if they were using a DDoS attack which crashes the server. These are a few of the things I thought of while looking at this script, the author hadn’t correctly configured the permissions in line with the script so that only an administrator could see this information.

XSS is very similar and so I won’t be doing a script by script analysis, infact, some of the scripts already mentioned had XSS vulnerabilities in them. What did strike me as important to note is a lot of these XSS vulnerabilities were executed straight after the admin had logged in, a great social engineer could pull of that the admin had typed their details incorrectly and could infact steal login details very easily. This image shows one of those examples. You register your name and it is shown on the first part of the admin panel.

hNot filtering PHP in upload processes seems to be a relatively big problem for coders which I surveyed. This first script allowed employees to message the other staff and management. This script allowed you to XSS in the message, but also allowed you to attach a file to your message. The file simply linked to the file location and so was very easy to locate, the author responded to my report of the vulnerability within a day (Modified WSO shell for anyone asking).

jAnother script shell vuln wasn’t huge but I still was able to upload a PHP file. I was authenticated as an admin and was able to upload a shell in the items area when creating a new item. I will say as I have before, just because it’s in the admin area doesn’t mean it’s safe, what happens if someone implements a staff level which allows the creation of items. The author has not responded back from my reporting of the problem. I used inspect element to find the URL, the string looks relatively random, although I didn’t upload multiple times.

k

The final shell was available to anyone who signed up, you had a profile where you could upload an image, easy enough, same as before inspect element to find the image. The author was quite pleasant when I reported the vulnerability and responded from my report within a few minutes.

lFinally, the last category of the vulnerabilities I found in CodeCanyon scripts, logic. Quite a broad sounding term which should be elaborated further with some examples. One of the vulnerabilities could potentially be put with information disclosure but decided to leave it here. The script was an invoicing script which allowed backups of the database, a feature common in CodeCanyon scripts, many though, do not need any authentication to download. You can guess the different tables with a bruteforcer if you have no knowledge of the script, very simple words like “clients” and “invoices” are used, we essentially are able to see all details of the database by simply going to the correct URL. If this was a randomised URL which only allowed one view and checked whether they were logged in would be sufficient, sadly, the system was not designed this way.

mThe other logic vulnerability is almost the same except from one step. In this particular web application a backup is named by the exact time and date it was executed on. We can still access these backups unauthenticated like the previous web application, but it could take some time to get the exact date,hour and second of a backup. Luckily I was able to find the script that executes the backup process. Again, this is an AJAX call page. We now know the time range of a backup from within a few seconds, we can now successfully guess the backup name allowing us to download a full backup of the sites database.

nThe other problem with this kind of design is that this could be used as a DoS attack. It’s so open that anyone can view this url and initiate the backup process. If the site has a relatively large database it could take some time to backup, if an attacker inititated 100 backups at one time it could atleast slow the web server down.

Conclusion

I think there needs to be an internal inspection on how CodeCanyon reviews it’s items, you cannot simply say it’s okay to sell a web application that’s vulnerable. They also cannot put this problem towards authors or buyers, ofcourse, every web application has a form of a vulnerability, but these aren’t abstract vulnerabilities that were hard to find, a few hours of my time provided a bunch of vulnerabilities that could destroy websites and servers.

Reviewing a web application less blind (with access to the admin panel) allows further inspection and easier detection of vulnerabilities. Many penetration tests are done where the tester must use web spiders to discover things like this, allowing access to the admin panel could actually prevent further vulnerabilities an attacker may find.

CodeCanyon please take security seriously, it’s how you’ll get more repeat customers, by helping developers understand security better and learn more.

Have some concerns? You can contact me by clicking the link at the start of the article.