SAP vulnerability: Why didn't the patch work correctly?

DHS reported on a SAP vulnerability, which had been patched in 2010, that has resulted in the breaches of three…


* remove unnecessary class from ul
$(“#inlineregform”).find( “ul” ).removeClass(“default-list”);

* Replace “errorMessageInput” class with “sign-up-error-msg” class
function renameErrorMsgClass() {
$(“.errorMessageInput”).each(function() {
if ($(this).hasClass(“hidden”)) {
$(this).removeClass(“errorMessageInput hidden”).addClass(“sign-up-error-msg hidden”);
} else {

* when validation function is called, replace “errorMessageInput” with “sign-up-error-msg”
* before return
function validateThis(v, form) {
var validateReturn = urValidation.validate(v, form);
return validateReturn;

* DoC pop-up window js – included in moScripts.js which is not included in responsive page
$(“#inlineRegistration”).on(“click”,”a.consentWindow”, function(e) {, “Consent”, “width=500,height=600,scrollbars=1”);

dozen global enterprises. The flaw enabled attackers to gain remote administrative access to the business information and processes on these systems. Why didn’t the patch work effectively, and what can enterprises do to ensure that their systems are secure?

SAP continues to run mission critical systems at many enterprises that still struggle with SAP security, including the security of supporting and other mission critical systems. These systems are often extremely complex, with significant customizations and integrated applications for supporting critical business processes. This causes enterprises to be wary of significant changes to a system. SAP released patches for the mitigation of this specific SAP vulnerability that requires a manual configuration and these patches would need to be tested thoroughly prior to deployment.

A reason why the patch hadn’t been deployed and used effectively is because enterprises may have been wary of the potential impact on custom applications integrated into their SAP environments that might rely on the specific SAP vulnerability functionality, which could be identified in a test environment. There also could be confusion about which group in the enterprise is responsible for patching the different components in a SAP environment, which may include the database, middleware (Java application server), Java, web servers and operating systems.

Enterprises running SAP should be aware of the risks of not following the SAP security recommendations within a reasonable period of time. Enterprises might assume that no one would find their SAP portals and that their firewalls protect their internal systems, but it is easier to find a vulnerable publicly exposed SAP environment than they might expect. The alert from CERT might prompt an enterprise with an unpatched SAP environment to expend the resources to protect its systems.

The first step for an enterprise is to determine if its SAP environment has been breached by checking the indicators of compromise released by Onapsis. Regardless of the logic behind requiring a manual configuration step to patch this SAP vulnerability, the software maker released security patches and enterprises should have processes in place for applying patches to all systems including mission critical systems. Vulnerable SAP components can be identified by using a vulnerability scanner to scan all systems related to SAP and then triaging these results.

Ask the Expert: Have a question about enterprise threats? Send it via email today. (All questions are anonymous.)

Next Steps

Learn how to maintain ERP and SAP security

Find out how to prevent ineffectual patching

Discover why an old Java serialization vulnerability did not get patched

Dig Deeper on Network Firewalls, Routers and Switches

Source link