back to article Almost EVERY SAP install hackable, researchers say

A staggering 95 percent of enterprise SAP installations contain high-severity vulnerabilities that could allow systems to be hijacked, researchers say. Researchers from SAP security tools vendor Onapsis say attackers can target the SAP installs to pivot from low to high integrity systems, execute admin privilege commands, and …

  1. This post has been deleted by its author

  2. Destroy All Monsters Silver badge
    Holmes

    Kull wahad!

    create J2EE backdoors

    Hold on, SAP is based on Java? And the 2003-ish enterprisy framework of J2EE (as opposed to JEE) from a time when Sun didn't exactly know how to even design such a thing? Say it ain't so!

    "The big surprise is that SAP cyber security is falling through the cracks at most companies due to a responsibility gap between the SAP operations team and the IT security team,”

    O'Really? You know the scenario:

    1) CFO demands SAP

    2) Ops say "We can't support this unless we get a big increase in manpower and clean up the existing shit & processes for a year or two"

    3) Board gives go-ahead because what does Ops know, they don't have business sense, wrong priorities and are not team players anyway

    4) Any outlays go to SAP "consultancy and configuration" no money left for any issues raised under 2)

    5) Wild installation into a "hands-off" operating mode where a super-expensive eejit drops by twice per year to "tune the SAP install"

    6) ????

    7) "WHY DIDN'T OPS TELL US THERE WERE PROBLEMS WITH SECURITY?"

    1. Anonymous Coward
      Anonymous Coward

      Re: Kull wahad!

      Sounds like the enterprise SAP deployments that I am genuinely aware of....

      1. Warm Braw

        Re: Kull wahad!

        Too true.

        The execs want a blinkenlight dashboard on their desktop so they can see how their enterprise is allegedly performing at every minute of the day, but they seem blind to the fact they have lost control of almost everything in their company (productivity through usability and pereformance, payroll and of course billing) in the process. Too many SAP users are almost entirely dependent in practice on external consultants and suppliers to manage these issues. Lack of security is a second-order concern when you've abdicated control and understanding of your key business infrastructure.

  3. Mark 85

    SAP is run by saps?

  4. Anonymous Coward
    Anonymous Coward

    SAP rhymes with Crap

    'nuff said.

  5. Anonymous Coward
    Anonymous Coward

    The flaws go deeper

    When training on SAP architecture and PI development years ago, a SAP security architect in their UK HQ took us through how ABAP code is setup and deployed. At the top you add entries for referential controls (which are in the app NOT the DB) and security constraints.

    I asked if these entries were mistyped or maliciously ignored, does that mean your code (SQL/ABAP) is running as GOD? After some checking the answer was yes and the security architect was rather shocked.

    SAP still does not have automated code checking in place, much code development is offshored and outsourced - because it doesn't matter that much does it?

    So an idiot or malicious hacker can get code into play to do almost anything in the underpinning database, which has no referential integrity in place and no security... Scary.

  6. SecretSonOfHG

    It is even worse

    It may sound dramatic, but the SAP vulnerabilities themselves are only the tip of the iceberg. The average SAP customers I know about are simply not prepared to patch so often and so much. Here's why:

    - Unless internal patching processes and regression testing are automated, all testing has to be done manually by very busy and already overworked administrative clerks. So at best what is going to happen is that patches accumulated over a long period, say 12 to 18 months, are applied in one big mud ball. This on top of the 12 months it takes SAP to release a patch. I have not seen SAP regression tests automated anywhere, much less the big piles of custom code written by assorted consultants over the lifetime of a system.

    - Most SAP shops don't apply any patches at all, unless they need to fix a bug. Due to the above mentioned lack of automated testing, and even if you have the requisite test/staging environments, regression testing is very resource intensive and thus avoided unless strictly necessary. "if it ain't broke don't fix it" is a very reasonable approach given the costs involved. Security is left as an exercise to the SOX compliance teams.

    - Due to SAP size and general lack of understanding of the security implications of its gazillion different modules, no one in its right mind exposes a SAP installation to the wild. This means that the above mentioned SOX guys get slapped by an "it is firewalled" response to most of its questions, and also means that most vulnerabilities, if exploited, will come from inside the organization.

    Of course, all it takes is a high profile SAP related security incident to change all that. But something tells me that if something like that happens we won't hear much from it unless it has national-budget proportions.

  7. Wombling_Free

    and that's how we do it in Austfailia

    I happen to know a very large retailer here runs entirely on SAP.

    And as far as I can tell, hasn't patched anything since, oh.... 2009? Maybe? When did Windows XP SP1 come out? well, whenever. Since then - thats the last update that shows up in the syslogs.

    What could possibly go wrong?

    1. big_D Silver badge

      Re: and that's how we do it in Austfailia

      My previous employer had outsourced their IT and I was their first in-house admin, back in 2010... Their PCs were all from 2003/2004 and none had had any updates since then. The PCs only had 256MB RAM, so the AV software (which was current) was set to never scan and not do real-time checks.

      In addition the support company had reset all passwords to 12345 and had told users that they could not change their passwords!

      Add to that the fact that the Exchange Server was configured to allow every user OWA / moile access (and the employee with mobile devices were all running Blackberrys over a BES server) from the Internet and the whole thing was a nightmare!

      The first things I did were to force password changes and disable OWA / mobile access. I then set about updating the hardware - I did make the mistake of trying to run a virus scan on the PCs, they were practically unusable for about 3 days!

      It turned out the sites were infected with Conficker and dozens of other viruses and nobody was aware of it. I was a real pain to clean up - especially as they were running 24/7 production and with Conficker you needed to keep the machines isolated, until the network was cleaned up. Try telling the production manager you need to take their machines offline for a day, because the controlling PCs need cleaning up.

      The best laugh was the PC in the sulphuric acid store, the motherboard was completely corroded. The user had been backing up - to a second partition on his local drive, because the network was unreliable (the network port was corroded).

  8. irrelevant

    Doesn''t surprise me

    I have an account with a major UK business that gives me access via SAP Netweaver Portal - one time, I connected and I was in somebody else's account completely! The company helpdesk simply wasn't interested; told me to log out, clear cookies, go back in again. Didn't even ask who I had ended up as..

  9. Anonymous Coward
    Anonymous Coward

    Architectural end of the road for Java

    Companies that have based mission-critical parts of their infrastructure on the JVM are hitting a wall across all areas - efficiency, security, stability. It's time to recognize the JVM has some deep theoretical mistakes that no amount of patching will ever fix.

    Even though it is a typed language, because of the myriad ways to bypass compiler-enforced assumptions, such as code introspection and hacks to the JVM - it's just as bad as if the system had been written in PHP.

    Part of the reason NSA's UDC never got off the ground and equipment was catching fire - they were using Accumulo, a Java-based DB. So there's a bit of good news, Sun's incompetence has prevented the NSA from fulfilling their Orwellian nightmare..

    1. Stretch

      Re: Architectural end of the road for Java

      duuuuuuuuuuh

  10. Dan 10

    Eye-opening stuff, including some of the horror stories in the comments. However, how many of these SAP instances are accessible from the corporate network anyway? If the host LPAR is in it's own network zone with only the appropriate ports open to permit access from an authorised front end, most of the risk is potentially from a malicious authorised dev/admin, no? Not that this is a small risk, but I can see why C*Os everywhere accept the risk...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like