Professional Documents
Culture Documents
Hacking Into A Billion-Dollar SAP Solution by Mario Morejon, CRN 12:12 PM EST Tue. May. 27, 2008
Hacking Into A Billion-Dollar SAP Solution by Mario Morejon, CRN 12:12 PM EST Tue. May. 27, 2008
Hacking Into A Billion-Dollar SAP Solution by Mario Morejon, CRN 12:12 PM EST Tue. May. 27, 2008
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.
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.
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."
In any company, the ERP (Enterprise Resource Planning) is the heart of the
business technological platform. These systems handle the key business processes of
the organization, such as procurement, invoicing, human resources management,
billing, stock management and financial planning. Among all the ERPs, SAP is by
far the most widely deployed one, having more than 90.000 customers in more
than 120 countries and running in Fortune 100 companies, governmental and
defense organizations.
This talk will present an old concept applied to a new paradigm: SAP Backdoors.
We will discuss different novel techniques that can be deployed by malicious
intruders in order to create and install backdoors in SAP systems, allowing them to
retain access or install malicious components that would result in imperceptible-
and-ongoing financial frauds.
After the description of these techniques, we will present the countermeasures that
should be applied in order to avoid these attacks and protect the business
information, effectively reducing financial fraud risks and enforcing compliance.
Furthermore, we will release a new Onapsis free tool that will help security
managers to automatically detect unauthorized modifications to SAP systems.
Is your SAP backdoored? If your answer is “I don’t know,” then you may consider
attending to this talk.
Talk Abstract –> SAP Backdoors: A ghost at the heart of your business
Introduction
SAP is the largest provider of business management solutions around the world
Backdoors
Very little public information on how they can affect SAP platforms. Just because it’s
not publicly discussed, doesn’t mean it’s not being used. We need to talk about this to
understand the risk.
The biggest mis-conception in SAP security is that SAP security is simply about
segregation of duties.
After gaining access, the attack can install a backdoor to maintain access.
By owning the OS or the Database, an attacker can install a backdoor and use it to
maintain control of the system.
The User Master is accessed when a user connects to the SAP system using the
SAPGUI. The password provided by the user is checked against the password stored
in the User Master.
SAP has however used a number of hashing mechanisms. Due to backwards
compatibility these older (insecure hashes) are still stored in the User Master. This
opens the system up to a number of attacks.
By default, the User Master stores the older version alongside the newer SHA-1
Demo –> Resetting the old hash –> Altering the profile –> attacker logs on with old
hash
As the attacker has only changed the old hash, the administrator can still logon
without problems (using his password). The attacker however, can still logon using
the old hash password he changed. This gives the attacker an almost invisible
backdoor, as there is no new account, and logs will not show the logon using the old
hash (with profile set to 4).
Protection
Monitoring the system values and check for changes. If the profile value is
altered, there is a problem
Implement dedicated authentication group for U* tables
Once you are logged in, you interact with the system running transactions. These
transactions are run using ABAP Programs/reports.
Unauthorized modifications at the SAP layer are possible, but not trivial
Why go the hard route, when an attacker can go straight to the database. There are no
CRC or signature checks on ABAP code stored in the database.
Demo –> Alteration of code in the database that changes payment information for
newly added user
PoC attack inserts ABAP bytecode into the database. The SAP system will then
compile and use it the next time the functionality is used.
Certain critical ABAP programs are protected to prevent access to the sourcecode.
The SAP system checks for a magic value (*@#@@[SAP]) in the first line of the code.
If it’s present, then the content is not returned. Alongside this check, there is also a
hard-coded kernel check to prevent access to the SAPMSYST (User Authentication
Procedure) and 2 other key functions. The check is however performed on the ABAP
program name. To bypass this, an attacker can create a new program in SAP and copy
the code from SAPMSYST to his newly created program. This will then bypass the
kernel protection as the name matching no longer triggers the protection.
Demo -> Reading and alteration of the SAPMSYST program to permit a backdoor –>
backdoor logs credentials to a logfile
As the SAPMSYST program is core to SAP, a restart of the process is required to force
the new bytecode to be created and the new backdoor functionality to take effect.
Protection
It’s not possible to detect and protect against backdoors from within the SAP
system itself.
External tools are needed.
Why you need it? It’s not feasible to detect backdoors from inside the SAP system
itself:
Onapsis Integrity Analyzer connects with the Database and performs “snapshots” of
sensitive ABAP report tables — Signature only, no ABAP code stored
Conclusion
Backdoored systems are not just an SAP problem, they can affect any kind of
system
If an attacker can gain total access to your database system, then it’s very
difficult to restrict their access to SAP
Backdoored applications can be a serious business impact
It’s all about the money
Automatic controls
Regular security checks
Vulnerability assessments
Penetration Tests
Security Audits
Onapsis’s Integrity Analyzer for SAP can help you to implement more in-depth
reactive controls.
What are the post installation steps after I have installed the Central Instance and
Database instance?
SE06
1. Select the Database Copy or migration option
2. Press the Post-installation Processing button.
3. When prompted Do you want to re-install the CTS?, press the Yes button
4. When prompted *for* the Source System of Database Copy?, make sure that the <SID>
of the production system is selected. Press the checkmark button to continue.
5. When prompted Change originals from PRD to QUA?, press the Yes button
6. When prompted Delete TMS Configuration?, press the Yes button
7. When prompted Delete old TMS configuration?, press the Yes button
8. When prompted Delete Old Versions of transport routes?, press the No button
TMS Configuration
1. Logon on to client 000 of the newly refreshed system.
STMS
1. Upon starting STMS, a windows with the title TMS: Include System in Transport
Domain should be displayed
2. The information on *this* screen is automatically filled out from information provided
during the SAP installation and should be correct. If it correct, then enter a description *for*
the system and press <CTRL>+S to save. Otherwise, press the Other configuration button
and manually configure.
3. From the Overview menu, select Transport Routes
4. From the Configuration menu, select Adjust with Controller
5. Press the Yes button when prompted *if* you want copy the transport routes from the
controller.
Import Printers
1. Logon on to the production client of the newly refreshed system.
STMS
2. Press <F5> to go to the *import* Overview.
3. Double click on the <SID> of the newly refresh system
4. From the Extras menu select Other Requests, then Add.
5. In the Transp. Request box, enter the transport number containing the printer definitions
that was exported. Press <Enter> to save.
6. Select the transport that was just added to the queue and press <CTRL>+<F11> to start
the import.
7. In the Target client box, enter the productive client of the newly created system. Press
<Enter> to save.
8. Press the <Yes> button to start the transport.
Client Configuration
SCC4
1. From the Table view menu, select Display -> Change
2. When warned that the table is cross-client, press the checkmark button.
3. Double click on one of the non-system clients (i.e. not client 000, 001 or 066)
4. Define client as follows:
Client role: Test
Changes and transports *for* client-specific object: Changes without automatic recording
Client-independent object changes: Changes to repository and cross-client customizing
allowed
Protection: Client copier and comparison tool: Protection level 0
Restrictions when starting CATT and eCATT: eCATT and CATT allowed
5. Press <CTRL>+S to save.
6. Repeat steps 4 through 6 *for* any additional clients
Import Users
STMS
1. Press <F5> to go to the Import overview
2. Double click on the <SID> of the newly refreshed system.
3. Press <F5> to refresh the list of transports
4. Locate the transport in the list containing the user exports done before the start of the
refresh.
If the transport is NOT in the list, then from the Extras menu, select Other requests then
Add. Enter the transport number and press <Enter>. Then press the Yes button to add the
transport.
5. Highlight the transport and press the Import request icon .
6. At the client *import* screen, enter the target client and then press the Import button
7. Press <Enter> to confirm that the *import* will proceed
SCC7
1. Run the Post Client Import Processing
2. The transport number should be the same as that of the transport started in STMS
3. Schedule the job to run in the background. Do NOT schedule it to run immediately.
We need to modify the job before it can be released.
4. Press <CTRL>+S to save.
SM37
1. Set the fields as follows
Job name: CLIENTIMPORT*
User name: *
Job Status: All options checked
Fr: 01/01/0001
To: 12/31/9999
Or after event: *
2. Highlight the job that was created by SCC7 and press <CTRL>+<F11> to modify the
job.
3. Press the Step button.
4. Select the RSCLXCOP line and press <CTRL>+<SHIFT>+<F7> to modify that step.
5. In the User box, enter the background user *for* that particular system (i.e BGDUSER,
SAPBATCH, BATCHSAP).
6. Press <CTRL>+S to save the changes
7. Press <F3> to go back to the main job screen.
8. Press the Start condition button.
9. Press the Immediate button.
10. Press <CTRL>+S to save the changes
11. Press <CTRL>+S again to save all the changes to the job.
12. Job will start immediately once saved. Press <F8> to refresh the list of jobs
13. Continue to press <F8> every once in a *while* to update the status of the job. Do not
*continue* until the job is completed sucessfully.
SCC4
1. From the Table view menu, select Display -> Change
2. When warned that the table is cross-client, press the checkmark button.
3. Double click on one of the non-system clients (i.e. not client 000, 001 or 066)
4. Set the Protection to Protection level 1
5. Press <CTRL>+S to save.
6. Repeat steps 3 through 5 *for* any additional clients
Reorganize Spool
SPAD
1. From the Administration menu select Clean-up Spool
2. Check all check boxes and enter 0 *for* minimum age
3. Press the Execute button
4. Once complete, press <F3> twice to get back to the main SPAD screen
5. From the Administration menu select Check Consistency
6. Press the Delete All button.
SP12
1. From the TemSe database menu, select Consistency check
2. When the check is complete, press the Delete All button.
SCOT
1. Double click on the green Fax entry
2. From the Supported Address Types area, press the Set button that is beside Fax
3. In the Address area, ADJUST AS NECESSARY
4. Double click on the green SMTP entry
5. From the Supported Address Types area, press the Set button that is beside Internet
6. In the Address area, ADJUST AS NECESSARY
SE38
1. In the Program field, enter RPUBTCU0
2. Press <F8> to execute
3. Select option BSI version 7.0
4. Press <F8> to execute
5. BSI should *return* tax calculations. If there are errors, take the necessary steps to
resolve.
Client Configuration
SCC4
1. From the Table view menu, select Display -> Change
2. When warned that the table is cross-client, press the checkmark button.
3. Double click on one of the non-system clients (i.e. not client 000, 001 or 066)
4. Define clients as follows depending on client role
Development
Client role: Customizing
Changes and transports *for* client-specific object: Automatic recording of changes
Client-independent object changes: Changes to repository and cross-client customizing
allowed
Protection: Client copier and comparison tool: Protection level 0
Restrictions when starting CATT and eCATT: eCATT and CATT allowed
Quality Assurance
Client role: Test
Changes and transports *for* client-specific object: No changes allowed
Client-independent object changes: No Changes to repository and cross-client customizing
allowed
Protection: Client copier and comparison tool: Protection level 0
Restrictions when starting CATT and eCATT: eCATT and CATT allowed
Training
Client role: Education
Changes and transports *for* client-specific object: No changes allowed
Client-independent object changes: No Changes to repository and cross-client customizing
allowed
Protection: Client copier and comparison tool: Protection level 0
Restrictions when starting CATT and eCATT: eCATT and CATT allowed
Sandbox
Client role: Test
Changes and transports *for* client-specific object: Changes without automatic recording
Client-independent object changes: Changes to repository and cross-client customizing
allowed
Protection: Client copier and comparison tool: Protection level 0
Restrictions when starting CATT and eCATT: eCATT and CATT allowed
SE06
1. Press the System Change Option button.
2. Set the global setting to Not Modifiable
3. Press <CTRL>+S to save.