Skip to Content
Technical Articles

Solving for the RECON Vulnerability

Key takeaways

    1. There are multiple ways to prevent exploitation of RECON, all with different pros and cons.
    2. Fixing or mitigating RECON involves interacting with each SAP JAVA system and potentially with each node, depending on the approach taken.

Introduction

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.

Fixing the 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

    • Cleanest way to secure your system, no chance of reverting back to vulnerable
    • The patch adds authentication and authorization to the vulnerable application
    • If the CTC application is needed to perform some task, with the patch applied, it would be secure to use it
    • Upgrading only the vulnerable application will leave an inconsistency among the other applications of the same component
    • It requires to actually apply the patch using any component updating mechanism available

Applying workarounds

There are 3 workarounds that will prevent the exploitation of the RECON vulnerability and we will discuss them in detail, highlighting pros and cons.

Deactivating the application aliases by server node

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:

    • ctcprotocol
    • ctc/core
    • CTCWebService

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

    • If the application needs to be used, it could be reverted
    • Defense in depth but not a final solution
    • Has to be performed in every server node
    • It could be reverted by some rare task in CTC application and the system would be exposed to RECON again

Stopping the vulnerable application

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

    • The application will be stopped in the whole system, despite having many server nodes.
    • If the application needs to be used, it could be reverted.
    • If the system is restarted, the application will be started as well exposing it to RECON vulnerability.
    • Not allowed to use this application in a safe way.
    • Defense in depth but not a final solution.
    • It could be reverted by some rare task in CTC application

Enabling authentication for the vulnerable service

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:

    • Basic authentication (user and password)
    • X.509 Client Certificate
    • Logon Ticket

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

    • Unauthenticated users cannot use the CTC application
    • The CTC web service will be authenticated in the whole system, despite having many server nodes.
    • A malicious user with valid credentials but no authorizations, could still be able to exploit RECON vulnerability.

In conclusion, there are multiple ways to prevent exploitation of the RECON vulnerability and each one has its own different pros and cons. However, applying the patch that SAP has released, is the easiest and fastest way to secure the ERP. Fixing or mitigating RECON with any other method could probably be reverted or bypassed.

References

The RECON Vulnerability Content Series

Back in July, SAP issued patches for the RECON vulnerability that was identified and disclosed to SAP by the Onapsis Research Labs. Because of the severity and the amount of potential vulnerable Internet exposed SAP systems, the DHS-CISA along with many other global organizations issued CERT Alerts warning organizations of the criticality of the RECON vulnerability. Both SAP and Onapsis urged organizations using SAP Applications to apply the patches immediately. In the days following the release of the patches for RECON, the Onapsis Research Labs and other security/threat intelligence organizations and researchers witnessed and reported rapid threat activity including scanning for vulnerable systems and ultimately weaponized exploit code posted publicly. This content is part of coordinated effort with threat intelligence experts, researchers and organizations to provide further insight, intelligence and actions you should take to ensure your organization is protected from the RECON vulnerability.

1 Comment
You must be Logged on to comment or reply to a post.
  • Thanks for the insights Gonzalo Roisman! This is super helpful to understand the best approach to fix the RECON vulnerability.

    This is part 2 of a 10 part series of different research perspectives around the RECON vulnerability, including Active scanning, Threat Intelligence, TTPs, Active Exploitation, Impact on the Cloud and many others. Many organizations contributed to this including Threat Intelligence Organizations, Non-Profit organizations and Research Institutions. If you want to get additional data points, you can check the blog #1 of the series, which links to all other parts.