US-CERT alert on SAP Cyberattack
On May 11, 2016, the Department of Homeland Security published the first-ever US-CERT Alert for cybersecurity of SAP business applications.
Nonetheless, what we do know from public sources is that there were threads on some Chinese forums related to the attack. However, is there any proof? I mean, I’m absolutely sure that cybercriminals perform attacks against SAP. I also believe that we should pay more attention to them and increase awareness. But as researchers and experts to whom the industry tends to trust, when we state that there was an attack, we ought to always provide IT community with solid proofs. I was personally involved in forensic investigation of SAP systems compromise and have no doubts that attacks are real, but I can’t disclose the details, that’s why I do not advertise that dozens of systems are under attack.
The original Invoker Servlet vulnerability
What kind of vulnerability was used and how dangerous is it?
As it was stated in the report, the attackers used an invoker servlet vulnerability.
We were the original authors who were first to describe how exactly that this misconfiguration can be used to exploit SAP Systems and thus can lead to cyberattacks. Firstly, the information about this misconfiguration was published by SAP in 2010. SAP stated that it would be better to disable this functionality if customers don’t use it. However, they didn’t provide any specific details about risks. In other words, the customers were not encouraged to disable it.
We [Alexander Polyakov and Dmitry Chastukhin] highlighted this issue at the BlackHat USA conference in 2011 during the talk titled “Crushing Blow at the heart of SAP’s J2EE Engine”.
To help companies to understand why this misconfiguration has crucial importance, what it allows hackers to do, and how to prevent its exploitation, we discovered an example of a vulnerable servlet which can be exploited because of this invoker servlet misconfiguration. This vulnerability was found in CTC servlet, and it can be used to perform almost any critical action in SAP such as creating a new user or reading any table. Later, we published a whitepaper and delivered a series of talks on an international scale to warn people about this vulnerability and help them to securely configure it.
As the issue is not easy to identify when you have a lot of services and a set of custom applications, we introduced a free tool called ERPScan WEBXML Checker that can be used to manually assess SAP Configurations and detect this issue as well as some others issues with J2EE web services functionality.
To make matters even worse, the vulnerability was not easy to patch either. First, it was necessary to analyze if an invoker servlet is enabled by default, then disable it and reboot the system. After that, you have to manually assess every web service (and there are 500+ of them just in a default J2EE installation) and check if invoker servlet functionality is enabled or disabled. If enabled, a task was either disable it or manually analyze a configuration file, if it is exposed any critical services which can be bypassed and then to configure it properly. Our tool also makes this process easier.
I can say that this tool was downloaded more than 300 times from our website in the last years, which may have prevented some attacks (at least I hope so). Now, as far as we know from the news articles, there are only 36 vulnerable companies and this number could be even bigger without our tool. In our turn, we, as always, tried not just to scare SAP users, but to do everything possible to protect them.
Real attacks on SAP using Invoker Servlet vulnerability
Sadly, there are no facts in this report that can be somehow proven by anybody except the original author. That is why I decided to check the facts myself.
The only interesting fact about the attack is this - ”The exploitation of the affected organizations’ SAP systems was publicly disclosed during 2013-2016 at a digital forum registered in China. In all cases, the individuals leveraged a publicly-known SAP application vulnerability, for which SAP had released a security patch more than five years ago.” - So, the only thing we know from trusted report is that on some Chinese forums we can find information that cybercriminals shared the data about vulnerable systems. I didn’t believe that cybercriminals published any relevant information in the wild. Within a couple of minutes, it turns out that on of the forums where Chinese white-hat community shares data on systems they can exploit and notify vendors and victims there were examples of systems which are vulnerable to the issue that we responsively disclosed back in 2011. It was a CTC servlet which was susceptible to invoker servlet bypass vulnerability. I found out that there were 44 posts with SAP hacking examples, all of them were using the invoker servlet vulnerability together on a critical web service that was also patched by SAP. The number of attacked systems - 44 correlates with the number of compromised companies (36 companies), taking into account that there can be multiple systems in one company. The countries involved are also the same, which allows us to conclude that we speaking about the same forum.
But the thing is that those examples were not the attacks but rather responsively disclosed issues by security experts from such companies as Baidu.
![]()
Here is one of the examples from this forum where experts share timeline of responsible disclosure:
2016-03-14：Details have been sent to manufacturers and vendors Processing
2016-03-15：Manufacturers have confirmed that the details disclosed only to manufacturers
2016-03-25：Details disclosed to the core white hat and experts in relevant fields
2016-04-04：Details to the general public a white hat
2016-04-14：Details disclosed to practice white hat
2016-04-29：Details to the public
So it turns out that most and probably all of those issues were sent to responsible authorities as listed in the status of vulnerability. Some vulnerability statuses are “It was handed over to third party institutions (CNCERT National Internet EmergencyCenter) processing” (translation of the last field on the screenshot below).
![]()
And for most of the issues we can find that there was a coordinated work with CNCERT to notify vendors “CNVD identify and reproduce the circumstances, it has been notified to the China Mobile Group transferred CNCERT, coordinated by the subsequent disposal site management.”
While in most posts that we analyzed we see that information was responsively disclosed. However, we can’t guarantee that nobody, including the authors really used them to conduct a cyberattack.
So, now we can see that those posts were not actually examples of cyberattacks and system compromise. But! Do not think that cyberattacks on SAP do not really exist. The other thing which worth mentioning here is that one of our Network sensors of global threat intelligence platform has recently (dd 12/4/2016, 14:19-14:20) identified the attack attempt exploiting the similar kind of issue, but as it was the only example against one sensor, we left that information internally for further investigation before publishing alerts.
The last but not least. At the end of 2014, we were asked to participate in forensic investigation project where the company was attacked via SAP vulnerability, and results of this project correlate with this data.
How big is the threat?
The matter here is not the fact of the attacks, but how many systems are vulnerable to this issue in addition to 44 systems identified, according to our investigation. Mathieu Geli – Head of SAP Threat Intelligence at ERPScan, revealed that approximately 533 systems across the globe (data obtained via non-intrusive network recon techniques leveraged by the open-source project IVRE) which are potentially vulnerable to one of the example of Invoker servlet vulnerability.
The other examples are by far more difficult to calculate. Those services can have unique names so that it’s not possible to get the final figure (approximately 500+ systems). Taking into account that most of them belong to Fortune 2000 companies, it’s quite critical issue to discuss.
![]()
Invoker servlet vulnerability – takeaways
So, at the end of the day, it doesn’t matter who was compromised and whether it was a real attack. The only thing that matters for the industry is how to prevent the issue exploitation. And I have an answer.
Information how to fix the vulnerability was published in our whitepaper, but here is a brief overview.
Prevention:
1) Update to the latest patch level that corresponds to your support package
2) Disable the vulnerable feature by changing the value of the “EnableInvokerServletGlobally” property of the JSP service on the server nodes to “false”
3) If you need to have an enabled invoker servlet for some applications, see SAP Security Note 1445998 for SAP NetWeaver Portal and SAP security Note 1467771
4) If you can’t install patches, you can check all the WEB.XML files using ERPSCAN WEB.XML Checker to find insecure configurations and locally enabled invoker servlets and manually secure all web services by adding protection to /* folder.
Recommendations
1) I was talking about it many times and continuing it especially now. A large number of SAP patches don’t exactly fix an issue as it seems to a unexperienced user. This situation relates mostly to configuration issues. SAP closes most issues by just introducing new parameters, which SAP administrators need to manually enable. That's why one has so many difficulties with Securing SAP Systems. Simply saying, you can't just implement patch. In most cases additional configurations are required after that. That's the most important takeaway.
2) SAP gives you a lot of customization functionality, so you can build your own apps where you should manually enable security features. Going back to our example, even if you disable invoker servlet globally, it can be enabled by any of your developers or admins. So, take a closer look at the customizations, and not only in this case, but in general. Check the source code of custom programs and authorizations for all users.
3) Finally, do not expose unnecessary services online. All of the 36 systems that may have been compromised had an administrative service were unnecessarily exposed to the Internet.
