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

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.

Comments

J2EE?

[viperidaenz]

Standard J2EE or an old Tomcat feature?

org.apache.catalina.servlets.InvokerServlet

It needs to be explicitly enabled to be active.

Re:J2EE?

[Sique]

It's the Standard J2EE feature. Its description is here: SAP: Invoker Servlet.

Re:J2EE?

[robmv]

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.

Meh. No biggie

[Anonymous Coward]

It's not like anyone can actually locate information in SAP in the first place. Could take decades for an outsider to figure out a business relationship, or the companies cost for something when you include the lag time for a simple query.

But but, I thought it was C that was insecure?

[Viol8]

Or that what we were being told a few days ago. How could a VM based language like java have exploits?? VMs are the future, right?

[/sarcasm]

Re:SAP?

[RobinH]

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.

SAP is not the problem here

[jools33]

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.

Re: SAP is not the problem here

[Anonymous Coward]

Without access to the system? Doubtful. SAP Netweaver Application Server Java (NW AS JAVA) will only disclose the version numbers of the different components on it if you have the right to view the system information page on its own or within the Netweaver Administrator (NWA), which requires membership in a particular group or a particular role to be assigned to your user. And usually there are a variety of systems throughout the landscape.

If an administrator uses SAP Solution Manager and uses the system recommendations functionality - it will automatically check the components and corrections installed on a given system and notify them of any security related SAP Notes (code corrections/knowledgebase articles) that apply to a given SAP system.

Also, just to point out GP's point- SAP patched this in 2010. You would have to be at a customer that didn't implement support packs on a system for more than five years.

Re: SAP is not the problem here

[OzPeter]

Also, just to point out GP's point- SAP patched this in 2010. You would have to be at a customer that didn't implement support packs on a system for more than five years.

Never having used SAP, is the system such that a "If it ain't broke, don't fix it" mentality exists? Or in other words does SAP have a history of borking updates?

Re: SAP is not the problem here

[Anonymous Coward]

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.

Re: SAP is not the problem here

[neilo_1701D]

So if I work for a business that uses SAP, is there a way for me to find out if it's patched and if my personal information is safe?

Maybe. Send Another Payment and we'll open a support case with your partner. Once we have the signed work order, we get agrement on the scope of the work and begin.

And remember: Send Another Payment.

Re:Meh. No biggie

[M0j0_j0j0]

SELECT * FROM BSEG , that should be enough.

Re: SAP?

[Anonymous Coward]

A.mishmash of technologies jammed together onto one platform that sells for millions. Expect to pay through the nose.

Traditional big iron shops have COBOL and DB2 on the back end processing millions of transactions per day on IBM mainframes running zOS or OS390 with midrange servers hosting java apps for the modern web interface, or CICS on the mainframe is their asses are not in gear.
Mixed in are a bunch of tools to support this.

Now. SAP. In the 1970s some dudes from IBM saw COBOL and DB2, said "what a bunch of shit! We can do better" and left IBM to develop their own tech. ABAP is a language which looks smells and feels like COBOL. The only difference is that the lifecycle promotion paths and environmental packaging and controls are stuck in the 70s. ABAP is effectively COBOL. HANA is the database the SAP guys dreamed up to combat DB2. It hasn't won yet. Give it time. They have yet to get out of the 90s in comparison with DB2. The SAP midrange machines run java jvms. Yay. Good on you guys for integrating java into the SAP stack.
There are a bunch of tools to support all of this.

The SAP guys then built some very crappy business software, ERP CRM etc - look it up ' for one client which they then adapted for selling to multiple clients. Their business model is to rock up to organisations paying millions to IBM and microsoft and say: Pour your databases into SAP Hana, convert your code and business rules to ABAP and pay us millions for licences. It will be better! One vendor! One database! What could possibly go wrong? It has to be better than COBOL! Mainframes are old tech! Go midrange! Don't be vendor locked! Come! Join us!

The stupid part is that they expect all data to be poured into their existing systems. ERP. CRM. Etc. Don't ever get anyone started on their business modelling tools and their grand plan to put all programmers out of work because the BA can code the business logic easily using the GUI.

What I really want to know

[Anonymous Coward]

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 !?

Re:SAP?

[Zocalo]

That's *raging* assole, specifically "One Raging Asshole Called Larrry Ellison".

Re:SAP?

[Big Hairy Ian]

Good developers who know SAP customization are paid a lot of money.

Who said they needed to be good?

Re:SAP?

[erp_consultant]

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.

Re:SAP?

[CCarrot]

SAP is like Oracle

^^^THIS.

I was so excited to be able to drop Lotus Bloats forever (and start the healing process) after I left my last job ...right up until I ran into SAP for the very first time in my new position.

Welcome back non-intuitive user interfaces, without even the pretense of internal consistency within itself much less anything outside it's own microcosm. Hello again cryptic and (again) inconsistent icon sets. So glad to see you again, labyrinthine layers of well-buried (but critical to actual use of the system, if you're trying to actually dig any data out of it) options and navigation paths. Oh, and the help? Hahahahahahahahahahaha! Reads like it's designed by accountants for accountants, but actually used for maintenance and work order tracking, so used more by tradesmen than finance-oriented people (at least our portion is)...oh, and if you can manage to figure out what cryptic-damn-buried transaction code you need to use, chances are you don't have permission to actually use it.

goddammit.