- Useful SAP System Administration Transactions
- Transactional RFC that can be used for remote code execution on SAP servers
- How to Hack SAP
- Editing data directly in database using &SAP_EDIT , can allow to gain SAP_ALL by editing authorization table data
- Hacking SAP BusinessObjects
- Spectacular hacks and workarounds from out there “in the wild”
- Blog with SAP basis tutorials
- SAP Security slides. Slides 28-29 got expalanation about Pass-the-hash in sap RFC calls
- Attacking SAP clients:
- SAP metasploit modules:
- Sniffing sap-gui passwords:
- SapCap – SAP GUI protocl sniffer / decompressor
- The script is a small PoC that is able to parse pcap files containing SAP GUI (DIAG) traffic and extract any SAP credentials found
- SAP environment defense system:
- SAP Penetration Testing Using Metasploit ( including SAP SMB Relay Attacks )
- sapyto is the first SAP Penetration Testing Framework
- ESNC Pentest Suite – SAP security scanner updated with latest exploits
- Attacking using bizploit:
- Download bizploit:
- Good comment on how to analyze sap security:
- “Ex SAP-BC/NetWeaver consultant gone infosec here smile emoticon I know a thing or two…
“Hacking SAP” is usually a matter of financial fraud rather than strict infosec. Like /u/thatstevelord said, SAP is a horrendously specific beast. However, in the end it’s still all just 1’s and 0’s, eh? So, yeah, SAP can be exploited, but it may take years to fully understand the architecture. That having been said, here’s a few pointers:
*Each SAP instance (or SID) is composed of three layers: database, application and presentation), each landscape usually consists of four instances: dev, test, QA and production. Each of the layers can be exploited to some extent, but most effect can be gained by attacking the database. As for the choice in instance: go for the QA system – you don’t want to fsck up your customer’s primary business processes.
*Each SAP instance is divided into clients. Each one has a user SAP, the application’s equivalent of “root”. Upon initial creation, this user SAP gets a default password: “060719992”. You’d be surprised if you knew how often these passwords aren’t changed in test or dev environments!
*Try to get access to the shell of any server using username <SID>adm. Bruteforcing can help.
*Try to get access to the database with user “sap<SID>”, “ora<sid>” or “db2<sid>”, depending on the DB used. Once you’re in, delete all records containing username sap* from table usr02. This will allow you to log in to the application using step 2.
*If they still use the old-fashioned ABAP-stack, use one of the many vulnerabilities in SAPgui. This is a crappy bugfest of a frontend, with many exploits. Google is your friend!
*Privilege-escalation from within SAP is a bitch, but it can be done. Gain access to transaction PFCG on a dev system, create a role and use STMS to transport the new role to a second system.
*SAP often uses the IBM Java environment. Supposedly, there are some nice exploits you can abuse over there. If the Sun/Oracle JVM is used; I know of no vulnerabilities in that landscape, but there are bound to be some.
*Figure out what modules the customer is using. Some of the more exotic IS (Industry Specific) modules are very buggy indeed. You’ll need industry knowledge for leveraging your exploits or demonstrating a proof-of-concept, though!
*Think “data”. SAP-instances often communicate with other systems (BI, ESS, yada-yada) and these interfaces can be attacked. It should be possible to spoof XML-messages from a BI-system and get a remote dump of the database, for instance. Hard work, but again: it can be done.”
- SAP ERP Central Component Security Guide
- Erp security related companies:
- ERP Security. Myths, Problems, Solutions
- Lecture from blackhat 2009 about SAP penetration testing
- SAP session fixation attacks and protection from blackhat 2011
- TDCodes search – useful to find interesting transactions