Communication Proxy

What is the issue?

An Improper Access Control vulnerability exists on the visual-ivr application. The /api/livechat/call/plaincall/__config endpoint allows unauthorized users to modify server configuration values such as UploadUrl and Proxy. This could lead to potential exploitation such as:

• Redirecting file uploads to malicious servers.
• Exfiltrating internal files through arbitrary path modifications.
• Exploiting Server-Side Request Forgery (SSRF) or unauthorized file reads.

How is this issue triggered?

The issue occurs because the DWR (Direct Web Remoting) configuration object is exposed to client-side access.

Specifically:

• The /visual-ivr/ endpoint interacts with /api/livechat/.
• The exposed methods setUploadPath and setDownloadURL allow attackers to change paths, enabling file exfiltration or downloading of internal files.
• Additional methods like setAllProxyURL and setServiceApiUrl could be exploited to manipulate proxy settings or API URLs.

Why is this a security risk?

The vulnerability introduces risks such as:

• File Upload Redirection: Attackers can modify the UploadUrl to redirect client file uploads to a malicious server.
• Internal File Exfiltration: The setDownloadURL method could allow reading internal files by pointing to arbitrary paths.
• SSRF and Misconfiguration: Exploiting other exposed methods can result in internal service compromise or sensitive data leakage.

How can the issue be resolved?

Remediation steps:

• Restrict DWR Configuration Access:
  • Remove the __config object from being exposed by modifying the dwr.xml file in the application server.
  • Action: Remove the following lines from <tomcat>/webapps/api/WEB-INF/dwr.xml:

               <create creator="new" scope="application" javascript="__config">
                       <param name="class" value="sg.ilink.Config" />
               </create>

• Remove Client-Side References:
  • Eliminate the script inclusion that exposes the __config JavaScript file.
  • Action: Remove the following line from <tomcat>/webapps/visual-ivr/index.html:

         <script type="text/javascript" src="../api/livechat/interface/__config.js"></script>

• Restrict Method Access:
  • Implement proper server-side validation and access controls to prevent unauthorized usage of configuration-modifying methods.
  • Validate all incoming requests at the API level.
• Deploy Secure Coding Practices:
  • Ensure that sensitive configuration objects are not exposed through public endpoints or client-side scripts.
  • Use role-based access control for administrative APIs.

Issue Description:

when Customer initiates a video call from Testapp (livechatsdk) , call does not reach to Agent (one-x agent ).

In problem scenario, customer is initiating the video call from livechatsdk and agent is receiving call on one-x agent softphone. Once Call received, agent pop ui pops up. Please note agent ui URL configured in one-x agent settings.

Initial Analysis:

Please check for Tcomm proxy, tcomm server, Media server logs for exception.

Search for "Msg Type" keyword in TcommServer logs. If Msg Type is "ChatHistory" then video call does not reach to agent.

If Msg Type is "CallAgent" then call should normally go through.

Resolution:

If the If Msg Type is "ChatHistory" then we need to change it to CallAgent.

First refer "rconfig" file of Tcommserver and "enable.callagentMsg" set to "true".

Then set "ICP_CALL_AGENT" to true in TCommProxy  app.config file.

Once the changes are done, please restart the services in order. Call should be able to received by agent.

Thanks,

Issue :Open Session Failed ,No log updates in TCommProxy,TcommServer,TPPVA

Cause :Session Time out value provided in Proxy configs, when the Value is SET to 0

Resolution :

Set the value of Session Timeout to required value (Ex 120 )

What is Reverse Proxy?

In computer networks, a reverse proxy is the application that sits in front of back-end applications and forwards client requests to those applications. Reverse proxies help increase scalability, performance, resilience and security.

Issue Description:

Chat Proxy isn't working using Nginx Reverse Proxy and gives 500 internal error (Null Pointer Exception) for livechat.js file

Troubleshooting:

Check the Nginx configuration file if the required proxy headers are provided. Below are the required headers.

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Resolution:

Set the required proxy header for specific application under location and restart the nginx.

Sample Nginx Config:

server {
listen 80 default_server;
server_name _;
access_log /var/log/nginx/access.log vhost;
add_header Strict-Transport-Security "max-age=31536000;includeSubDomains;preload" always;

error_page 401 402 403 404 405 444 500 501 502 503 504 /custom_error.html;
location = /custom_error.html {
root /usr/share/nginx/html;
internal;
}

if ( $request_method !~ ^(GET|POST|PUT)$ ) {
return 444;
}

location /api/ {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://<IP-ADDR>:<PORT>;
}
}

Requirement:

For mapping the Customer Identifier (CIF) in the VIVR URL would require primary reference value (Ex: UCID/ACCOUN_NUMBER/LOAN_ID) into GBL_Interaction_history. So that reporting module can fetch the reference fields and represent in OCM reports such as AVPlayback report etc..

Configuration:

1. Pass the parameter in the URL as query string that is declared in VIVR config.                            Ex: https://nabilbank.tetherfilabs.com:8443/visual-ivr/captcha?intent=main&ucid=110215594558024250&node=75241665-42c4-4170-b3ea-f2f67083afd8
2. The query string should be a variable predefined in "VIVR" custom headers.  The same header needs to be mapped in comm proxy customer json.
3. In TMAC Server --> chatJsonConfig.config file, map the Query string value declared in comm proxy  customer json to TMAC variable. Ex: "node: "CIF". where value of query string "node" will be mapped to "cif". Hence the value of column "CIF" in GBL_Interaction_history table will be the value of "node".

Load balancer is an infra component in a network architecture used to manage the incoming requests to backend servers. Configuration at the load balancer determines the type of the HA Cluster. URL or IP or Port based routing configuration can be achieved in this layer. This device can also act as a reverse proxy when required.

The device will also have the provision to setup stickiness of the session, so that interruption in signaling and session connection is handled efficiently.

I.e., If requests from the users’ network (internet) are distributed to back-end application then it will be HA Active-Active setup.

If requests are routed only to primary server and to secondary (DR) during fail overs, then HA cluster is Active-Passive.

Configuration:

• When there is a web server (such as Tomcat) behind a load balancer, and has an application deployed which maintains a 'user sessions', it is important to make sure all the requests for a single user session is routed to same WebServer (Tomcat). If the LB keeps distributing the requests among all Tomcat servers, the application logic will fail to execute because it requires a user session to be there.
• To achieve this, a concept called 'session stickiness' is used. Load balancers has the ability to configure session stickiness which ensures the requests from a particular user session is sent to the same Web Server (Tomcat).
• A 'COOKIE' is used in achieving the session stickiness.
• For TCommProxy/ChatProxy, the cookie name is "JESSIONID".
• The "JSESSIONID" is created and inserted into each RESPONE by the 'livechat api'. The load balancer can detect this cookie and create a record in LB to map JSESSIONID to Web Server ID.
• Every subsequent requests coming from livechat sdk (UI/VIVR/ChatBot) will have the JSESSIONID cookie which got generated by server in the first response. When the request reaches LB, it can detect the JSESISONID cookie and find out the mapped Web Server ID. Then LB will forward the request to particular Web Server.
• Cookie Persistence Timeout should be more than the average user session active duration.

Troubleshooting:

LB will generate a cookie and insert to the session in the first request. Browser or client  console can display the cookies used for the session. Client should send same cookies for every subsequent requests. If client fails to send then stickiness will not work. The cookie value for any signaling URL request should remain constant throughout the session.  Constant cookie value acknowledges the stickiness of the  client and server session.  Screen shot below is for VIVR application where '/api' is the for which JSESSIONID is inserted at LB.

Most of web application running on a Tomcat might have cookie named as 'jsessionid' (all small letters) which might  create some confusion with chat API's JSESSIONID. So, make sure you verify the case sensitivity and the application path (i.e /api) while checking the cookie.

When the TComm Proxies are deployed behind a LB and the LB has not configured the JSESSIONID cookie correctly, the UI application will face below behaviors:

The UI application will keep getting "No Session Found" errors. And if you check the TComm proxy logs, there should be a keyword 'UnOpenedSessionNotAllowed'. If this keyword is present, it is a strong indicator that there is something wrong in LB session stickiness.

References:

• https://javarevisited.blogspot.com/2012/08/what-is-jsessionid-in-j2ee-web.html#axzz721H78GWK
• https://swagger.io/docs/specification/authentication/cookie-authentication/
• https://www.f5.com/services/resources/white-papers/cookies-sessions-and-persistence
• https://www.haproxy.com/fr/blog/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/
• https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-local-traffic-manager-implementations-14-0-0/configuring-http-load-balancing-with-cookie-persistence.html

load this url and check if captcha enabled https://ip:port/api/proxyconfig.jsp
Check if any empty file named captcha under /tomcat/conf/config

a) Issue Description:

TComm Server shows logs "Routing to Agent via 'WorkQueue'" twice for the same session

b) Cause

CallAgentMessage config of TComm Server and AutoCallQueue config from TComm Proxy not in sync

c) Troubleshooting

Duplicate queuing for same session happens when AutoCallqueue on TComm Proxy config is set to true and enable.callagentMessage of TComm server rconfig is set to false. Ensure to keep both configs to true so that session queuing happens only once for one chat session request.

Below screenshot shows AutoCallQueue config in tcomm proxy config

Below screenshot shows enable.callagentMessage config in tcomm server rconfig

a) Issue Description:

TComm Server shows logs stop at session start and doesnt show routing and callqueue after that

b) Cause

CallAgentMessage config of TComm Server and AutoCallQueue config from TComm Proxy not in sync

c) Troubleshooting

Call routing and queuing won't happen in TComm Server for new session request when AutoCallqueue on TComm Proxy config is set to false and enable.callagentMessage of TComm server rconfig is set to true. Ensure to keep both configs to true or false so that call routing and queuing happens for the new session request

Below screenshot shows AutoCallQueue config in tcomm proxy config

Below screenshot shows enable.callagentMessage config in tcomm server rconfig