In an earlier blog post I wrote about the SAP audit logging capabilities. When you have your security audit log activated, without the use of filters, you -no doubt- have a great affinity for SAP security. During my daily SAP project work, when speaking at conferences, when meeting clients, I continuously warn for a false of security.
Beware of the placebo effect
Running regular security audits, which may highlight configuration glitches imposing security vulnerabilities, is absolutely recommended. I can only praise organizations for executing code vulnerability analysis on their entire code base.
However, even when running a fortified system, one can never entirely prevent malicious activities. SAP Identity Management, Single-sign-On, Unified Connectivity, ...all these technologies will definitely help reducing the risk. Moreover, a general security awareness is triggered.
Mind the gap
Using a textbook example I will showcase how identity theft can be executed and how this gets highlighted within the SAP security audit log. For obvious reasons, I do not want to write a hackers manual, the example scenario uses an attack pattern which is (or at least should be) mitigated since long within your SAP landscape.
You do not need to be a SAP expert to compromise a SAP systems.
You have to be a genius to do so without leaving any breadcrumbs.
In the scenario below I am a developer, happily coding within a development environment, having genuine access to a SAP GUI. As you might have guessed already, the same attack pattern is technically also possible without even having access to the SAP GUI.
Each SAP instance is equipped with a function which allows a developer to generate, run and instantly delete a program. Indeed, sounds like an ideal tool to go in stealth mode when generating "temporary" code.
Function RFC_ABAP_INSTALL_AND_RUN is even opened for remote or external calling. When browsing the SAP support portal or online forums you will see this function is heavily discussed and its usage in more recent SAP version has been secured like Fort Knox. The function module contains about 160 lines of code, 95 lines of these lines only deal with basic authorization checking.
For the example scenario we will not execute the function in a production environment containing confidential data. No, we will just run it locally, within the development box, where I have all required authorizations.
When you know a guard is on duty you will be careful not to awake the watchdog
Now, I did find an ABAP-program to read password hashes on the internet. A password hash is the encrypted string for a user password. The output of the ABAP-program can be used directly with one of the many available password brute-force or decryption tools. Such tools may not be build for SAP, they do the job just fine since SAP uses standard hash algorithms.
To avoid detection by static code analyzers (aka CodeInspector, CVA, ....) we do not create a regular ABAP-program. Instead, we use the above mentioned function to perform an ABAP code inject.
The injected program, copied from the internet, instantly returned all users and password hashes from the system. Immediately after execution the program self-destructed.
Security Audit Log
When checking the standard security audit log we do see some breadcrumbs left behind: a program with the name Z$$$XRFC was started shortly after initiating the function module test framework. The code inject was thus not executed entirely in stealth mode.
Note the alert above is not marked as critical, nor will you have any idea on what has been executed. Since we do execute this within a development environment chances are very realistic the message will be lost in the mass volume of log entries, when non-production logs are verified at all.
Closing the gap
Using a real-time intrusion detection system (IDS), like e.g. SecurityBridge, audit log data is continuous evaluated against potential attack patterns. In here we separate the music from the noise. The below screenshot was taken from the SecurityBridge events monitor on my iPad, which highlights the ABAP-inject immediately after execution. Somehow I also have the habit of writing blog posts on the weekend.
Next to providing speaking alert message the IDS also transferred the alerts into the corporate security information and event management system (SIEM). This way your security operation center receives instant SAP insight.
If one would create a local program to extract the same password hashes manually the IDS would also instantly identify the issue due to an embedded code vulnerability analyzer:
The steps shown above, extraction of password hashes from a development box, may only be the preparation phase of an actual security breach. Once passwords have been decrypted it is very realistic the same users and passwords actually also work within the production environment.