At Troopers 14, JP and I gave a talk called “Anti-Forensics on SAP Systems”. The talk focused on the methods attackers could use to hide their tracks on an SAP system. This blog post highlights one of the attacks we discussed.
SAP BusinessObjects has long supported Auditing and it has been enabled within the product by default for a number of years. By design all Audit events are written to the Auditing Data Store (ADS) on a schedule. However, as BO is designed to be a distributed platform, there is a delay between the moment when an event occurs and the time that event reaches the ADS. As discussed in the Administrator Guide, the steps before an event reaches the ADS are as follows:
- After an event occurs (e.g. Logon, Report Generation) the Auditee writes the event to a temporary file.
- The Auditor polls all auditees for new events on a set schedule. In BO4, the polling interval is dependent on the utilization of the Auditor. Higher utilization means that the Auditees are polled less often. In one of the lab system’s the delay is typically 3 minutes with 1% utilization.
- If an auditee has new events, it takes them from the temporary file and sends them to the auditor in a batch.
- The auditee waits to receive confirmation from the auditor that the events have been received.
- After confirmation, the auditee deletes the events from the temporary file.
To reiterate from the steps above, there is a delay between when an event occurs and when the event is written to the ADS. During this delay the audit events are kept in a temporary file on the Auditee’s filesystem. This leaves the attacker a window to modify or delete the event in the temporary file before they are written to the ADS.
The demo we used in the talk is discussed here.
First, we had the Administrator login to the Central Management Console (CMC) Web Application. Below we show the Polling Cycle Duration and that the user Administrator is logged in.
Next, the attacker sees that one of the temporary files has been updated on the Auditee filesytem. Opening the file she can identify that the Event has an ID of 1014 (i.e. Logon) and see the CUID of the Administrator user (the red box below).
The attacker modifies the CUID to the Guest CUID (a disabled account). Notice the value in the red box has been changed from the first picture.
The temporary log has now been poisoned to hide the user that logged in. The attacker waits until the Auditor polls the Auditee and the entry is placed into the ADS.
To verify success, we show that the last user to login was ‘Guest’ rather than ‘Administrator’.
A report listing users that have logged in recently will erroneously report that the Guest logged in when, in fact, it was an Administrator.
Note on Defense
This method requires that an attacker has write access to the Auditee’s temporary files which would likely require a privileged OS account.
It is also important to build an entire picture when reporting on the ADS. For example, a sloppy attacker may correctly modify the login event but forget to co-ordinate the SessionID, Tomcat logs, or an action event that may occur much later (e.g. Report Generation, Logout).
The Administrator guide has detailed information on Auditing within BusinessObjects.