SAP Products and OpenSSL Heartbleed

There has been a lot of discussion last week about CVE-2014-0160, also known as the Heartbleed vulnerability. For those unfamiliar with the vulnerability I recommend heartbleed.com and, for a light hearted explanation, XKCD. Along with impacting a good chunk of the Internet it has also taken a toll on a number of products including those from Cisco, VMWare, and Oracle to name just a few. As you can imagine we have been watching the issue pretty closely and performing testing in our lab in order to better understand the impact, if any to SAP and its customers.  Here is our current understanding on the status of some of SAP’s products:

Vulnerable

Continue reading

Share Button

Hiding Breadcrumbs – Antiforensics on SAP BusinessObjects

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:

  1. After an event occurs (e.g. Logon, Report Generation) the Auditee writes the event to a temporary file.
  2. 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.
  3. If an auditee has new events, it takes them from the temporary file and sends them to the auditor in a batch.
  4. The auditee waits to receive confirmation from the auditor that the events have been received.
  5. After confirmation, the auditee deletes the events from the temporary file.

Continue reading

Share Button

Simple Powershell Process Monitor for Fuzzing

While doing some fuzzing recently I ran into trouble with Sulley’s (https://github.com/OpenRCE/sulley) process monitor. For those who are unfamilar, when fuzzing, the process monitor hooks into the target process and grabs valuable information in the case of a crash (e.g. register values). It’s job is also to restart the process when it crashes.

In my use case I was doing remote fuzzing of a network service. On the target system, the service I was fuzzing had to be started by another executable. Confused? Think of the workflow like this,

C:\MyTargetMaster\> master_process.exe -startprocess mytargetProcess -port 9999 -username Administrator -password boomboom

As you can see above master_process was starting another listening service (mytargetProcess) on port 9999. In this case I already knew there was a crash possible in the service I just needed better information about the exploitability during automated testing, hence process monitor. Unfortunately, this scenario was not playing nice with Sulley so the workaround I chose was Powershell.

do{
  $Running = Get-Process <MyTargetProcess> -ErrorAction SilentlyContinue
  if (!$Running) {
    $arguments1 = "-startprocess <MyTargetProcess> -port 9999 -username Administrator -password boomboom"
    Start-Process "C:\MyTargetMaster\master_process.exe" $arguments1
    Start-Sleep -s 10
    $arguments2 = "-pn <MyTargetProcess> -cf cmd.ini -loga results.txt"
    start-process "C:\Program Files\Debugging Tools for Windows 64-bit\cdb.exe" -UseNewEnvironment $arguments2
  }
  Start-Sleep -s 3
}
while(1)

The script above:

1. Checks to see if a specific process is running
2. If it’s not running, start the Process with relevant arguments
3. Hook the cmd line version of WinDBG (cdb) onto the process and run the script cmd.ini. Log the notes from each crash to results.txt; “-loga” appends to the log file so it will contain the results from all the crashes.
4. If the process is running, it sleeps for 4 seconds.

The cmd.ini script is simple but useful. In the case of a crash it runs the !exploitable (http://msecdbg.codeplex.com/) WinDBG extension to determine the exploitability of the crash. It then records the register values at the time of the crash. If you are using Peach (http://peachfuzzer.com) you are probably already doing something similar.

g;!load MSEC64;!exploitable;r;q

And that’s it! Tracking which packet caused the crash is an exercise left up to the reader but it’s not too difficult following the Sulley session and the order of crashes.

Share Button

Abusing File Sending Privileges in BusinessObjects Launch Pad

One of the features of BusinessObjects Launch Pad (formerly InfoView) is the ability to send a file to another user. By default, there are no restrictions on the types of files that can be sent. This can be handy on a Penetration Test when you might have Guest privileges and like to target specific users (e.g. the Administrator Group).

1. Login to the InfoView application. Go to Documents tab, New > Local Document. Make sure to add a convincing description. 2. Right click on the file and go to Send > ‘BI Inbox’ . Select who the file will be sent to. Notice, in the screenshot below we have selected the Administrators group. The ‘Use Specific Name’ field at the bottom can be used to rename the file. In this case we rename the file to ImportantDocument.zip (a similarly agnostic file type). In the third screenshot we show the file arriving with the title ImportantDocument.zip (rather than SuperSweetPayload.exe as it was originally named).

A Note on Defense:
An administrator can limit the types of files that can be uploaded using the CMC. In particular, limit the “Agnostic” file type to prevent executables.

Share Button

A Simple Method for Fingerprinting SAP BusinessObjects

The main component of a BusinessObjects installation is the Central Management Server (CMS). It’s rarely changed and default TCP port is 6400. A simple way to identify if you are communicating with a BusinessObjects installation is to make a socket connection to the remote server and send the string ‘aps’. If everything is running correctly you should receive the IOR of the CMS.

Note that the hostname of the server is given at the end of the response which is useful in further attacks. Furthermore, if you parse the IOR you will get the IP and port of the CMS’s dynamic listening port which can be added to your Reconnaissance data.

A note on Defense

The most critical point of prevention is firewalling the CMS from unauthorized connections.

Share Button