Slashdot Mirror

← Back to Stories (view on slashdot.org)

Attackers Targeting Critical SAP Flaw Since 2013 (threatpost.com)

Posted by BeauHD on from the five-year-old dept.

msm1267 quotes a report from Threatpost: Three dozen global enterprises have been breached by attackers who exploited a single, mitigated vulnerability in SAP business applications. The attacks were carried out between 2013 and are ongoing against large organizations owned by corporations in the United States, United Kingdom, Germany, China, India, Japan, and South Korea, spanning 15 critical industries, researchers at Onapsis said today. [The DHS-sponsored CERT at the Software Engineering Institute at Carnegie Mellon University also published an alert this morning, the first in its history for SAP applications.] The severity of these attacks is high and should put other organizations on notice that are running critical business processes and data through SAP Java apps. The issue lies in the Invoker Servlet, which is part of the standard J2EE specification and enables developers to test custom Java applications. When it is enabled, developers and users can call these servlets over the Internet directly without authentication or authorization controls. Attackers, however, can take advantage of this same functionality to exploit these business critical systems.

7 of 57 comments (clear)

  1. J2EE? by viperidaenz · · Score: 3, Informative

    Standard J2EE or an old Tomcat feature?

    org.apache.catalina.servlets.InvokerServlet

    It needs to be explicitly enabled to be active.

    1. Re:J2EE? by robmv · · Score: 4, Informative

      The invoker servlet and its default mapping /servlet/* isn't present in old nor current specs. It is not a JEE standard or was. It was a feature many JEE containers copied mainly because Tomcat at that time was the reference implementation (The invoker servlet class was on the tomcat package namespace not on the javax.servet one) , a very bad idea. It is not present in modern containers.

      Since 2002 is known that having it enabled was a bad idea. But you know, enterprise software is badly updated.

  2. Re:SAP? by RobinH · · Score: 4, Informative

    Most companies above a certain size run a type of software called "Enterprise Resource Management" or "ERP". The functionality is a bit nebulous, but it can include everything from purchasing to HR, inventory, ordering, fulfillment, etc. It's the software that essentially runs the business. There are lots of ERP systems out there, but SAP is a very very big (probably the biggest) one. There's probably some statistic about X% of fortune 500 companies use SAP as their ERP system. It's kind of notorious for being 1) expensive to license, 2) expensive to customize, 3) expensive for users to be trained on, and 4) generally sold more on the pretty graphs management gets to see rather than on the usefulness it brings to the company. Good developers who know SAP customization are paid a lot of money. Typical SAP implementations for a large business will run into the millions of dollars easily.

    --
    "I have never let my schooling interfere with my education." - Mark Twain
  3. SAP is not the problem here by jools33 · · Score: 3, Informative

    SAP patched this problem back in 2010, and issued security notes for it made available to all its customers, and notified them all. The problem here is that some customers don't pay attention to their security notices and carry on regardless.

    1. Re: SAP is not the problem here by Anonymous Coward · · Score: 3, Informative

      Depends on the customer and while enterprise software has longer support lifecycles, changes can and sometimes do brick things. Most SAP customers try to be at least proactive on security patches for obvious reasons.

      Even patchlevels within an SAP support pack level can break things. It's not common, but when you change the way a method works to secure it, a dependent program or call might not work. This is why you generally have at least a two tier landscape (development & production) and usually a 3-tier (development/quality/prod) or 4-tier landscape (dev/pre-q/QA-prod) for SAP - so you can breakfix your changes.

      The flaw described in OP is from the Netweaver Java side - not the 40+ year old ABAP side. In ABAP, you can patch the system for most code corrections while it is online, without taking it down, and just patching the specific symptom or program you want. In Java, you have to take it in the patchlevel of a component - meaning you have to apply it to the system (taking some downtime) and taking whatever other corrections are included in that component. The patches in OP were not exclusively part of support packs (where new functionality could be introduced), meaning there was a lower risk of change.

      Most larger SAP customers generally tried to implement at least an SAP Support Package stack at least once every 1-3 years, with patchlevels in Java coming per SAP recommendation. While customers I went to were generally good about applying security related SAP Notes in Application server ABAP, sometimes customers were less proactive on the AS Java side.

  4. What I really want to know by Anonymous Coward · · Score: 2, Informative

    I came here to see the comment that answers what 'between 2013' means. I am surprised that no one is nitpicking this yet. Where did all the grammar nazis go !?

  5. Re:SAP? by erp_consultant · · Score: 3, Informative

    Had to weigh in here....

    SAP is either the #1 or #2 (depending on which stats you believe) ERP vendor. ERP is just a fancy term for integrated software. In the past many companies would have one vendor for their Accounting software, one for their Payroll, and another for Inventory. And so on. Often these disparate systems would be written in different languages with different data models making it very difficult to pass information from Accounting to Inventory, etc. For really big companies we could be talking dozens or even hundreds of systems.

    SAP (as well as Oracle, Workday, NetSuite) comes with built in integration.You can buy as many or as few modules as you like knowing that they are designed to work together. That's a big deal for huge companies.

    The other selling point is regulatory compliance. Big companies are subject to an enormous amount of regulatory compliance from various government agencies and this type of software is built around that.

    Is it big and cumbersome and expensive? Sure. But it's not as expensive as not being able to ship your products, or take customer orders, or pay your employees. Bottom line...the software works. When things go wrong it's usually because of poor decisions.