Advanced Guestbook v2.4.4 [0day]

            _
             | |          mark
             | |===( )   //////
             |_|   |||  | o o|
                    ||| ( c  )                  ____
                     ||| \= /                  ||   \_
                      ||||||                   ||     |
                      ||||||                ...||__/|-"
                      ||||||             __|________|__
                        |||             |______________|
                        |||             || ||      || ||
                        |||             || ||      || ||
------------------------|||-------------||-||------||-||-------



Error-Based MySQL Injection:

The 'uid=' GET param is vulnerable to error-based MySQL Injection on most pages. There are a few pages within the panel where this param is not vulnerable for some reason, but in the majority of pages it is possible to perform SQLi via this param:

Vulnerable URL example:
http://site.com/advancedguestbook/admin.php?action=settings&panel=general&session=YourID&uid=1%27

In addition to this being vulnerable to SQLi, it also makes the job of exploiting it a hell of a lot easier. Firstly, it discloses the PHP version, OS, and type of HTTP daemon in use in the output for the error message. You can find an example of the error message below:

MySQL Error : Query Error
Error Number: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1
Date        : Sun, April 21, 2019 22:28:16
IP          : [REDACTED]
Browser     : [REDACTED]
Referer     : [REDACTED]
PHP Version : 5.6.36-1+ubuntu16.04.1+deb.sury.org+1
OS          : Linux
Server      : Apache
Server Name : [REDACTED]

The table names are static and are the following:
- data
- auth
- config
- com
- ip
- words
- ban
- private
- smilies
- pics
- captcha

In addition to this, the MySQL username + database name + MySQL hostname have static default values.
MySQL User / Database Name = cms_agbook
MySQL Hostname = localhost


Local File Inclusion:

The HTTP GET param 'tpl_name' is vulnerable to Local File Inclusion and Directory Traversal. You can read everything within the default webroot directory by changing the value for 'tpl_name=' to the file that you want to read, or you can pair it with Directory Traversal to be able to read files on the local file system (this is using an include(); function too, so its confirmed LFI rather than LFD, meaning it is essentially RCE).

Vulnerable URL Example:
https://site.com/advancedguestbook/admin.php?action=template&tpl_name=../../../../../etc/passwd&session=YourID&uid=1
Image Example ('passwd' file output):


Cross-Site Scripting:

The 'tpl_name' HTTP GET param used for the Local File Inclusion is also vulnerable to non-persistent reflective XSS. There are no filters in place, and your inputs are being reflected straight to source rather than reflected within a specific context (e.g. as the attribute for a tag, or within a JS code snippet between <script> tags) -- this means you can simply input your own HTML/JavaScript code without first needing to break out of a specific context or to bypass any filters. The fact this isn't context-specific means that it is easier for people to bypass Chrome's XSS auditor with this vulnerability as any auditor bypass will work rather than you having to craft one that is also context-specific.

Vulnerable URL Example:
https://site.com/advancedguestbook/admin.php?action=template&tpl_name=<script>YourCode();</script>&session=YourID&uid=1

There is no HttpOnly cookie set in HTTP headers by default, meaning session hijacking is a possibility. Once you've hijacked a session, you can exploit the vulnerabilities listed above, or you can simply head over to the 'Templates' page, change the code for a template name to include your PHP shell, save it, and then navigate to that template within your address bar.

As an alternative to hijacking an admin session (and in my opinion the thing that makes this bug worth posting) you can use fetch(); in your XSS payload to make the authenticated admin perform a request on your behalf, allowing you to spawn a shell within a single click with a properly crafted payload in use (e.g. you could first connect to the site with the code for a PHP shell as your user agent header, then you could craft an XSS payload via fetch(); which links the admin to the LFI vuln while including /proc/self/environ to automatically spawn a shell for you). phpinfo(); output is also available to admins, so you could view env vars and other useful info by crafting a payload with fetch and some additional JS code, then change the value for the 'action' GET param to '&action=info' (although there's not much point in this considering you could craft an XSS payload to trigger RCE through a single click using the vulnerabilities listed above)



Blind Persistent/Stored XSS:

In addition to the reflective XSS listed above, there is also a stored blind XSS made possible through the use of image filenames. This does not require admin authentication. The following steps can be used to reproduce the bug:
Choose a regular image (with a common image extension e.g. JPG or PNG) and rename it to an XSS payload
As a regular (non-admin) user, leave a comment on the guestbook and attach the image named as your payload
Wait for the admin to log in and navigate to the 'Easy Admin' area of admin panel. As soon as this happens, your XSS payload will be triggered