Being extra careful with "exposed" FIORI / OData solutions

[jose_sequeira]

Hello @All,

 

I've been researching a few solutions for sometime now and came across something that i had to write about, the new "exposed SAPUI5 apps to the internet" movement. Analyzing some of those apps, i've came across multiple scenarios, but today i'm here to talk about exploits (the importance to prevent them).

The complete and detailed analyzes that i did, i've used to open a vulnerability report on the official SAP channel:

Form sent...

So here, i'm just going to share some thoughts and showcase of what could go wrong if you leave some "doors open" on your environment (to prevent you from doing it!).

 

Let's first talk about SAPUI5:

SAPUI5 on the internet

 

We have to remember that this apps now, on the internet, can be analyzed by many audiences (good and bad), so we have to be extra careful on what to "leave" on the source and how to model the OData service.

Example (found on internet searches):

It's nice to validate Captchas on the frontend, but if the validation procedure is placed on the source code, it can be easily bypassed:

And they can target the service that get's called after the validation, so here you could place the validation else where.

Also, if you're thinking about using a "exposed SAPUI5" with an OData service API (that could also be open), remember to consider the possibility of your service getting hit by any Dos/DDos attacks:

Image from Google.com

So extra security layers or API Managements are really important here, please consider that. Also, if you're OData service is "open" and not well designed, some information about the server or sensitive data could be extracted from them, please design it carefully.

 

Let's now focus on OData services:

I'm not going to tell you how, but by some internet researching (detailed on the document sent to SAP) anyone can find companies that use the User Self Service solution to some portions of Gateway User Management (official documentation Here and a Blog Here😞

So if the customer was found on a internet search, it means that his environment is open to the internet.Taking a look at the official documentation, it should probably be "open", even without CSRF_TOKEN validation:

Going deeper on the documentation, we can see that it uses the Reference user concept to allow users to be created using the Self Service (read more Here😞

Reference User

So if you're using or plan to user User Self Service ❗️attention here❗️. It's extremely important to carefully design the role/profile of the reference user, because if it's a "too open" profile, could lead to exploit scenarios.

Also, (read more about Here) described on the official documentation, please specify the OData services that the reference user could execute:

Attention here!

Don't put a * on this part (as i've seen many customers do❗️❗️❗️):

Dont do that!

Please take a deeper look on OData roles/profiles Here and Here if you've any questions, and let's make OData profiles "stronger" 💪.

🕵️ Now, for DEMO purposes, i'm going to simulate an attack on a "open" on Premise FIORI / Gateway environment with ❗️❗️❗️BAD ❗️❗️❗️ role/profile configured, that is using User Self Service (I'm gonna use Postman for OData calls).

Again this is a controlled sandbox environment, just to demonstrate how this standard services combined with bad config can "harm" your company/customer.

Let me first remotely request my user creation, that will be created based on a reference user (⚠️ with bad config ⚠️), let's call it MRROBOT:

Creating...

201, created

After that, got the activation email:

Activation Email

So i could active on the URL (fake one here) or using OData calls as well (on the documentation).

After successfully creating the user and activating, now i can login on the FIORI Launchpad:

Launchpad Login screen...

Im in...

We could explore the scenarios of request password reset, change user data, etc. Now, looking inside the server, here is the created user:

SU01 - 1

SU01 - 2

😲 So as you could see, i've remotely created an user and logged in the launchpad, but what else could i do? Again not gonna detail everything, but to demonstrate how dangerous bad role/profile config can be let's go a little deeper. As you know, we have the list of active OData services on the environment:

/IWFND/MAINT_SERVICE

This services can be of standard FIORI Apps, Z apps, integration, etc., and some of them can contain sensitive data to the customer.

By exploring, also using OData calls, i can also see the same list on Postman (due to bad profile, not restricting the OData services that the Reference user could execute):

Your OData service list...

So let's assume that this company was an Airline Company, and with the standard DEMO "Sflight", we could get sensitive data like Flight Carriers:

Sensitive data...

Also, i could even get a list of Active Users on the environment, to be used on other type of attacks (social engineering, etc):

Active Users...

So in summary, let me make some final comments:

1. If you're using User Self Service, as you could see, it's really important to have well designed roles/profiles for reference users.


2. If you're a developer and your SAPUI5 app and/or OData service is getting exposed to the internet, be extra careful on what it's gonna be exposed on the entities and in your code.


3. If you've an open SAP Server with open OData services, think about extra layer of security to prevent from attacks like Dos/DDos.


4. If you're using User Self Service, design a well "support flow" when users request more access on your environment, because some social engineering could be done after remotely creating unwanted users, to get more access.

Hope it helps someone...and let's make our customers safer!

Stay safe.

PS: Yesterday was the safe internet day.

Regards.