Hacking Into a Billion-Dollar SAP Solution

The Waldorf, Germany-based company is examining potentially alarming scenarios, brought to its attention by our Test Center, which found that one data store built on SAP technology revealed an easy opportunity for cyber criminals to gain access to a large corporate database.

Fritz Bauspiess, director of SAP NetWeaver product management security, says the company is looking at the issue brought to its attention by the Test Center earlier this month.

"The [SAP] team will work to see if they can replicate the issue and verify it, then will create a recommendation to customers on how to address (if one does not already exist)," Bauspiess said.

The Test Center first began examining the issue earlier this month and, working with an SAP engineer for one large corporation, who talked to us on condition of not being named, pointed out the scenarios. The Test Center examined the specific deployment first hand, and identified the weaknesses.

To wit:

Security holes left in messaging servers and enterprise services are the most exploitable. The messaging tier is by far the most active application stack on most enterprises and hackers are well aware that companies sometime simplify the security processes in order to speed up development cycles.

The techniques used targeted SAP's Sales and Distribution, and Material Management modules. But the same techniques will work on all SAP ERP modules, according to our expert. The flaw lies in the openness of the system itself. SAP's Web Service .Net connector allows remote BAPI calls as well as direct raw IDOC files to pass through.

There are no checks that can prevent hackers from accessing records by using a listener. To get to that stage, hackers have to be able to connect to a message queue or gain access to native ports.

TIBCO's EMS (Enterprise Messaging Service) and other TIBCO services products that are implemented with SAP R/3, for instance, depend heavily on JMS [Java Messaging Service] queues. Applications running inside TIBCO's stack are designed to simply route messages to SAP's BAPI. If the JMS queues are left public, hackers can easily bypass TIBCO's stack and connect directly. Because TIBCO uses a proprietary BPEL engine, it is tougher to pass messages directly through its native environment, so it is generally considered more secure. The caveat is the access layer to the queue, of course.

Java has been in decline for quite some time as development shifts towards .Net in the enterprise. On some vertical markets, Java is reaching the point of becoming legacy technology. According to our source, .Net is playing a key role in the way MOM architectures today are being redrafted. One issue is performance.

TIBCO's BPEL is expensive to maintain and it is generally considered slow, so companies looking to improve transaction performance replace their TIBCO products with in-house .Net applications. Companies also are finding that the work to link processes to SAP through message queues is not difficult.

To bypass adapters, developers build their SAP IDOC XML Schemas manually. The algorithm is simple, for each segment in a IDOC-XML document, so identifying fields and determining offsets and lengths can be constructed with Altova's XML tools in minutes. In fact, all one needs to communicate directly with SAP is the XML Schema for all of its modules. And here's where the vulnerabilities can arise.

On large and complex projects, test code often ends up becoming production code. Companies that get used to using Public MSMQ Message Queues continue to use them in live systems. Since MOM servers reside behind firewalls, there's little danger of breaking into them, or so they think.

Public queues are the super highway for hackers. Custom applications can also be a double-edged sword for organizations. On the one hand, .Net applications are agile and more dynamic but on the other hand administrators have a tough time tracking many micro size services. The architecture creates an opportunity to execute foreign code.

Like JMS, hackers only need to write a simple XSLT construct that map IDOC to an internal SAP Schema. Crafting a fake IDOC gives hackers unlimited access to an entire IDOC store.

Creating a simple listener is the next step. Once the listener reads off the queue, hackers can easily reroute responses somewhere else like to a file, another queue, email, and external Web service. To secure the traffic, developers have to get used to writing AD-based private queues and encrypting messages between the Web tier and SAP. What's more, the SAP store must be designed to accept encrypted keys to verify the validity of the messages.

In addition, companies that are still using legacy file directory based queues by Sun's EGate, for instance, are vulnerable. Anyone with general access to application servers can simply drop IDOC files and they would be processed by EGate and then forwarded over to SAP for further processing.

Anyone one of those communication points discussed could be exploited because they become the transport agent to hit an SAP store, and each one can be peeked at to see what they are sending. This architecture is a nightmare for IT administrators.

While companies that fail to secure SAP stores generally do not pass most IT audits, managers sometime take the simplest route to get systems up and running. According to our source, IT managers sometime cheat and pass compliance audits by taking a messaging stack out of production and replacing it with legacy brokers that provide one-to-one access to a SAP store or temporarily divert traffic to TIBCO or other legacy BPEL engines. The messaging system remains in prototyping stages while an audit takes place. This decision can save IT thousands of man-hours but it is shortsighted. In the end, messaging systems must be encrypted regardless of the layers of security in put in place.

Bauspiess of SAP said the company carefully works with partners and customers to keep them aware of best practices. Bauspiess said in an email:

"1. SAP builds carefully crafted security functionality into its products that helps customers create a secure environment, such as identity management, SOA security, authentication and single sign-on, authorization management, and much more. 2. SAP sets high standards internally around software security and quality assurance in its products that are followed throughout its product development organization worldwide. 3. SAP provides detailed information, services and support to help customers create a secure environment for their valuable business data. In support of these three pillars, SAP offers a security response team to handle any customers security issues that come up. The team replicates the issue and then works closely with the customer to address it in a timely manner."