Hacking Into SAP

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. TIBCO's BusinessWorks for SAP R/3, for instance, is simple a wrapper around JMS queues, so it is 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 technologies. According to our source, .Net is playing a key role in the way MOM architectures today are being redrafted. One issue is performance.

Companies looking to improve transaction performance replace their TIBCO BPEL implementation with a .Net. TIBCO's BPEL is expensive to maintain and it is slow. What's more, companies 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 end up becoming production code. Companies that get used to using Public MSMQ Message Queues continue to use them in live system. Since MOM servers reside behind firewalls, there's little danger of breaking into them or so they think.

Public queues is the easiest way to break into SAP. This is by far the easiest way with this MSMQ architecture. 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 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 story 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, there's a short cut that managers sometime make to pass audits. According to our source, IT managers cheat and pass audits by taking a messaging stack out of production and replacing it legacy brokers that provide one-to-one access to a SAP store. 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.