Why big companies ignore SAP security patches — and how that could bite them, big time

By Byron V. Acohido

Threat actors in the hunt for vulnerable targets often look first to ubiquitous platforms. It makes perfect sense for them to do so.

Related article: Triaging open-source exposures

Finding a coding or design flaw on Windows OS can point the way to unauthorized to access to a treasure trove of company networks that use Windows. The same holds true for probing widely used open source protocols, as occurred when Heartbleed and Shellshock came to light.

There is yet another widely-used business platform that malicious hackers have turned their attention to. It is SAP’s enterprise resource planning (ERP) applications.

SAP serves as the digital plumbing for dozens of multinationals; it is deeply embedded in 87 percent of the top 2000 global companies, enabling and integrating ERP functions, such as sales, production, human resources and finance, as well as other core systems.

SAP is no different than any other complex software. Vulnerability researchers, ranging from penetration testers to threat actors, continually seek out fresh security flaws which SAP subsequently issues patches for. The trouble has been that SAP patches can be troublesome to implement, and so very often get postponed.

In 2016 the U.S. Department of Homeland Security’s Computer Emergency Response Team (US-CERT) issued three separate security alerts warning SAP customers to install security patches, including one issued six years earlier that had gone widely ignored.

Many large enterprises have been lagging in SAP patches. This exposure is pervasive. And it is only a matter of time before threat actors pull off a high-profile data breach.

Last Watchdog recently sat down with Alex Horan, director of product management at Onapsis, which supplies SAP cybersecurity and compliance solutions, to discuss the broader implications. For a full drill down please listen to the accompanying podcast. Here are excerpts edited for clarity and length:

LW: It has only been fairly recently that SAP security flaws have come to come into the spotlight. Why so?

Horan: Previously, attackers couldn’t really get their hands on these systems to understand them and learn how to attack them. And then two things happened: they got deployed in the cloud, in a practice environment, where they could be accessed very quickly and cheaply; and the second thing was everything else got more secure. Over time, as the other fruit basically raised up, these systems were left dangling. And now we’re seeing them as the target of attacks.

LW: In what way is this low hanging fruit?


Horan: The big thing is that it’s a very complex system for which everything was left on by anonymous default, because this made it easier to set up and configure. So it was deployed with everything turned on. As a result, everything is available and the attack surface is massive. And often, unauthenticated access that will give you full control can be gained by a simple mis-configuration.

The vendors are saying, ‘This is how you should secure it.’ And people are saying, ‘It’s running, we don’t want to change it; we rely on this openness, and if we start enforcing security, we’d have to change in the rest of our environment to allow for that change.’ It’s a very costly change for enterprises to make.

LW: Meanwhile vulnerabilities get discovered and patches get regularly issued. How’s that playing out in the real world?

Horan: Everything we saw 20 years ago in server technology we’re now seeing repeated in these enterprise applications. These are vulnerabilities made by humans, and deployed by humans.The vendor (SAP) is patching the flaws, but the problem is the enterprises aren’t deploying the fixes. It’s because uptime is king.

LW: What evidence is there that this is being exploited in the wild?

Horan: It was actually exploited. There was a screenshot published in a Chinese hackers forum showing main, large U.S. enterprise Internet-facing servers being compromised through this vulnerability. The vulnerability allowed you to issue commands through a web interface, for a SAP portal system, and create your own administrative level accounts on that interface, and also interact with the underlying operating system. The FBI had to contact each of these enterprises and let them know what was going on. And we worked with them to help them resolve the problem.

LW: How do companies tend to view this exposure, at this point in time?

Horan: What we’re hearing, to some degree, is that the lack of a massive breach is stopping people from shifting their focus onto these systems. A lot of enterprises are very reactionary. They look at what happened yesterday, and say, ‘Could that happen to us? Let’s stop that.’ So they’re waiting for something big to happen to justify taking steps to stop it from happening. We see a lot of inertia. Companies are being pulled in a lot of directions, with all these business enablement projects going on.

LW: So how bad are the vulnerabilities that are lurking in place?

Horan: These systems are designed to fit inside very different enterprises, so they can be configured in a multitude of ways. There’s lots of information regarding best practices for configuration. The problem is that a lot of times these systems were deployed by a consultant, who’s more concerned about speed. Let’s get deployed and running. If something’s not quite working. Let’s just elevate the permissions and let that go through. So we’re seeing a lot of configuration-based problems.

LW: Sounds perfect for motivated criminals.

Horan: Exactly. These systems lead to payroll information,  customer information, it’s got all that stuff. It’s not something you can just throw some software at and it magically goes away like. It’s something that takes dedication and a willingness to fix. First, you have to measure and understand the scope of the problem you have.

LW: And then what?

Horan: And then just break it down into chunks. Beyond saying ‘I think things are bad,’ get specific. If, for instance, complying with GDPR is a concern, determine what aspects can be fixed that will both improve security and help meet compliance. So it ends up turning into a series of projects.

Then, after you get to a good state, it’s just maintenance every month; monitoring how vulnerabilities affect you, and deciding which ones you’re going to address, so it becomes an ongoing process.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone