The RECON (Remotely Exploitable Code On NetWeaver) vulnerability, rated with a CVSS score of 10.0 out of 10, has numerous ways to fix/mitigate the associated risks. Even though there is only one solution recommended by SAP, we will discuss in detail both the fix and the possible workarounds for this vulnerability.
The first recommendation is to apply the patch immediately which consists of installing the patch for the LM Configuration Wizard (LMCTC) component. This component contains a particular application called “tc~lm~ctc~cul~startup_app”, which starts the Central Technical Configuration (CTC) Framework. This framework enables an SAP user to perform several semi-automated actions, and it is usually used for post installation tasks.
As this vulnerability affects SAP JAVA systems, SAP Note #2934135 provides a patch to be implemented. This patch is a new version of the LMCTC component and it should be deployed as soon as possible. This patch adds both authentication and input path validation to the affected web service, therefore an attacker will not be able to perform critical actions such as creating an administrative user, neither to download files from a directory if the patch is applied.
Organizations typically find challenges on applying patches to SAP JAVA systems since it usually requires a system restart. In this case, however, a reboot of the system is not necessary so there will be no downtime associated with the application of this patch in the system.
As an alternative, it is possible to upgrade only the vulnerable application by extracting its patch from the component’s patch, hence there is no need to upgrade the whole component. More detailed information about this can be found in the 9th item of the SAP Note #2948106 [3].
Pro | Cons |
|
|
There are 3 workarounds that will prevent the exploitation of the RECON vulnerability and we will discuss them in detail, highlighting pros and cons.
SAP’s most recommended workaround is to deactivate the application aliases on each server node (SAP Note #2939665). Application aliases are, as its name suggests, aliases or alternative names that point to a web application. Each application’s deployment descriptor specifies its application aliases prior to deploying the application. These are mapped to a URL pattern used to access the resources of a web application. For CTC application, there are three of them:
When accessing this application, the most commonly used is the last one listed before, giving as a result something similar to the following URL:
http://<host>:<port>/CTCWebService/CTCWebServiceBean
The problem with this approach is that the change has to be applied in all server nodes. Server nodes are used as a load balancing mechanism by SAP. For example, when a user logs in to an SAP AS Java, the system chooses to connect to the server node with less load. It is possible to have as many server nodes as desired.
The application aliases exist per server node. This means that to mitigate the impact of RECON vulnerability, the application aliases should be disabled in every server node. Otherwise, a remote malicious user could potentially login to a server node that has the application aliases enabled, and exploit the RECON vulnerability. To perform this, the Telnet protocol allows an administrator to connect to a particular server node, check the status of the application aliases, disable them and then jump to other server nodes. Therefore, if the NetWeaver Application Server Java has multiple server nodes, this hardening process needs to be performed in each one of them.
SAP warns their users that this workaround is reversible, and also, it might be temporarily reverted by some rare task in the CTC application.
Pro | Cons |
|
|
Stopping the CTC application is a workaround as well, because it leaves the application disabled for use. However, as the previous one, this workaround can also be reverted. If the system is restarted, the application will be started, leaving the system vulnerable to RECON again.
The aforementioned application can be stopped by following the path: ‘Operations > Systems > Start & Stop > Java Applications’ in any SAP Java system.
Image 1: Affected application being stopped
In order to decide if this workaround can be applied, the SAP logs should be checked to see whether the CTC application was used lately or not. Stopping the vulnerable application is required to be executed only once per system and not per node, as the previous workaround.
Pro | Cons |
|
|
Last but not least, another possible workaround for RECON vulnerability is to enable the authentication in the web service configuration. The LM Configuration Wizard application of SAP NetWeaver AS JAVA does not enforce authentication by default. Adding authentication to this web service will still expose the system to a vulnerability with CVSS score of 9.9 out of 10.0, because an attacker with a valid user but no specific authorization would still be able to exploit it.
Having said that, it will prevent any unauthenticated attempt to compromise the system through RECON, which greatly reduces the number of potential attackers.
The service definition can be modified in the ‘Single Service Administration’, which can be found in ‘NWA > Configuration > Connectivity > Single Service Administration’. System administrators can add to the CTCWebService:
Image 2: Enabling authentication on the affected application
Any authentication method will work, however SAP recommends to deactivate the vulnerable application or at least its application aliases so that it cannot be accessed (see workarounds above).
Pro | Cons |
|
|
References
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
37 | |
10 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
2 | |
2 |