Invited Author: Juan Pablo Perez Etchegoyen (jppereze@onapsis.com)
Key Takeaways
By analyzing the activity/traffic of a large network, it is possible to spot scanning attempts potentially performed by threat actors.
Scanning for the SAP NetWeaver JAVA default port increased significantly after the release of the patch for the RECON vulnerability.
A good indicator of interest around vulnerabilities and threats is how much different individuals or actors are actively looking for that vulnerability—but what does this mean in technical terms? Looking for a vulnerability, specifically for a remotely exploitable one, starts by identifying the TCP port that is associated with the vulnerable service.
Once the attacker knows the TCP port, the actor will try to search for the vulnerability by first doing a network scan, sending specially crafted packets to detect if the port is open or not. There are a number of different ways of doing this, including the oldest and most widely-used network scanner, nmap.
When it comes to well-known ports supporting widely-used protocols, such as HTTP on TCP port 80 or HTTPS on TCP port 443, it becomes difficult to separate who is trying to discover what without looking at the actual Application Layer protocol and segregating the intent by identifying the actual URL a user is connecting to.
In the case of the RECON vulnerability (CVE-2020-6287), the situation is a little bit different, as the vulnerable component is configured by default in a port that is not widely used by other well- known TCP services, the SAP NetWeaver JAVA HTTP service in TCP port 50000. This makes it easier to measure interest by only looking at the Network Layer (TCP in this case) and filtering traffic that is heading towards the aforementioned TCP port.
It is important to mention that the RECON vulnerability affects a service that is exposed through the HTTP protocol and, even though it is configured by default in the TCP port 50000, ultimately, the TCP port that will be exposed to the internet could change, in fact, most organizations that purposefully expose business applications do that through HTTP, adding an encryption layer of SSL or TLS and when doing so, most organizations choose the well known port 443, where every browser will point to, when specifying a url with HTTPS and not specifying the port number.
Having said that, looking at statistics around the default SAP Netweaver JAVA HTTP service provides a good indicator of how much more attention this service could have due to a new and critical vulnerability.
Analyzing the data
Compiling the network data for publicly facing systems of the Czech Technical University in Prague [2], which includes roughly 5000 IP Addresses, can provide some alternative data points to understand the interest around detecting potentially vulnerable SAP Applications. Always filtering by TCP 50000, at first glance looking at the hourly data points there are some indicators of increase but nothing conclusive. Initially, it is possible to take June as somehow an indicator or normality, as it was before the release of the patch (July 13th, 2020). In that way, June provides the baseline to compare against in the following months (July and August).
After analyzing the baseline in June, it is possible to explore what happens in July, where it is possible to visually identify an increase in the back side of the month. That is evidenced by a 33% increase in the mean of the number of daily connections to the TCP port 50000.
Finally during August, this trend continued to increase, providing an increase in the mean of 190% compared to June.
Putting it all together
Combining the data points of all three months, it is possible to visually identify the increase in the trend of daily connections by adding a polynomial trendline of 3rd degree, which better illustrates the slope during June-July as well as the increase during July-August.
So what does it mean? Well, it could be many things, of course, but seeing this increase in the time frames of the release of the patch and the release of public exploits correlates very well with the increase of network activity in the relevant TCP port. In other parts of this series (Part 4, 6 and 7), other data points indicating Threat Activity as well as automated active exploitation/scanning will be presented that further validate these last findings and assumptions.
References
[2] Czech technical university in Prague: Home - Public web
The RECON Vulnerability Content Series
In July, SAP issued patches for the RECON vulnerability after being identified and disclosed to SAP by the Onapsis Research Labs. Because of its severity and the amount of internet- exposed SAP systems potentially vulnerable, 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 a 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.
Links to each part of this blog series can be found below:
● Part 1: The Vulnerability @Onapsis Blog
● Part 2: The Mitigations @SAP Community Network
● Part 3: Relevance to the Cloud @Cloud Security Alliance
● Part 4: Threat Intelligence @DigitalShadows
● Part 5: Active Scanning @Stratosphere Labs
● Part 6: Tools Techniques and Procedures @BlueLiv
● Part 7: Active Exploitation @Onapsis Research Labs
● Part 8: Compliance @The Institute of Internal Auditors