April 30, 2014

If you've worked within SAP Security for a while, chances are that at some point a request may have been brought up for "Display Only" access within one of your systems. This may have been requested by auditors, configurators, consultants, or even a really "needy" end user. Whatever the reason may be for it, you may have pondered how best to create such a role. In the following post, I will go over the process that has worked best for me in my current environment in order to tackle this particular request. This is by no means the only way to perform this, nor is it necessarily the "best" way. It is merely what I've found to work, and what I prefer.


I. Create a Security Role copied from the SAP_ALL Profile
The first thing you'll need to do is to create a new Single Role with its Authorization Profile copied from the SAP_ALL profile. This will add most, if not all, Authorization Objects into the role. The steps to perform this task are:

1. Using transaction code PFCG, create a new Single Role. For mine, I used the name ZS_DISPLAY_ALL_AUTHS.
2. Click the Authorizations tab, selecting "Yes" to save the role first.
3. From the Authorizations tab, click the "change Authorization Data" button. If you see an informational note, just click the green check-mark to continue.
4. As you haven't added any Transaction Codes to the role, the system should now be prompting you to select a template for the role. For this, you will need to select the SAP_ALL template, and then click the "Adopt reference" button.

Make sure to select the SAP_ALL profile as your template for this role.


5. If you are prompted to insert all authorizations, click "Yes." This may take a few minutes, and will be followed by another prompt. As before, just click the green check-mark to continue.

II. Modify the Security Role to have only Display permissions
Once you have imported the SAP_ALL template into your role, you will need to make some modifications to it in order to ensure that it provides display only access. As the SAP_ALL profile provides near-complete access to an SAP system, this is an imperative task to perform. Unfortunately, it can also be quite time consuming.

1. First, you will need to click on the Organization Levels button in order to edit what Org. Levels are defined within this role.
2. Click on the "Full authorization" button and then save your changes.

As this Security role is for Display All access, you will need to apply full authorizations for the defined Org. Levels.


3. Next, drill-down into the Cross-application Authorization Objects (AAAB) Object Class until you find the Authorization Object S_TCODE. Expand this Authorization Object.
As you can see, the S_TCODE Authorization Object has a value of *. This allows for ALL transaction codes to be ran.


4. From the expanded view of S_TCODE you will need to click the Deactivate button (red minus symbol) to deactivate this Authorization Object, and then click the Delete button (trash can) in order to delete S_TCODE from this role. If you are prompted for the deletion, click "Yes" to continue.

After you have ensured that S_TCODE has been deactivated in the role, you can delete it.


5. Once the S_TCODE Authorization Object has been removed, you will need to manually go through each Authorization Object in the role and change the ACTVT values to reflect the display only design of this role. This can take quite a while, and it is highly recommended to save frequently as you work. When you are finished, ensure that the Profile is generated and you can begin the next step.

This is an example of what you will need to perform against the vast majority of Authorization Objects in this role.


III. Create a Security Role with the desired Transaction Codes
After you have modified the Display All Authorizations role to no longer have any Create, Change, Modify, etc. permissions within it, you will be able to create separate Security Roles that only provide access to the Transaction Codes that your user(s) need Display All permissions to. Remember the S_TCODE Authorization Object we removed earlier from the other role? We are going to use it within these roles. The following is an example as to how to create one of these "transaction only" roles.

1. Create a new Single Role, providing it with a descriptive name. In this example, I will use the name ZS_DISPLAY_ALL_BASIS.
2. Just as how you would create a typical SAP Security Role, you will need to assign the desired Transaction Codes that you want to provide display access to.
In this example, I am adding some SAP BASIS transaction codes.


3. Just as before, you will need to click on the Authorization tab and then click the "change Authorization Data" button. Again, if you see an informational note, just click the green check-mark to continue.
4. Just as how you deactivated, and then deleted, the S_TCODE Authorization Object in the previous steps, you will need to do this for every Authorization Object except for S_TCODE.
When you have removed all of the other Authorization Objects, this is what should remain.

5. Now you can generate your role's profile, and save it.


Using this process, you should now have a Single Role that contains the vast majority of Authorization Objects within SAP, with the exception of S_TCODE. These Authorization Objects should also all be configured to provide Display permissions, without any form of Create, Change, Modify, etc. You will also have another Single Role that does the opposite by containing only the S_TCODE Authorization Object, with the assigned transaction codes in-place. This role, however, provides no additional permissions.

When you assign both of these Security Roles to an end user, the system will determine what transaction codes they can run via one role, and will determine their level of access (display, if everything was configured correctly) via the other role. Using this methodology allows you to more quickly create Display Only roles, as you will only ever have to create a Single Role containing the necessary transaction codes (remembering to always remove the excess Authorization Objects from the role). After creating the role containing S_TCODE, you can just assign this new role and the previously created ZS_DISPLAY_ALL_AUTHS role.

January 31, 2014

Back in 2009, when I was still a college student, I was required by one of my online class to use a web-based application that allowed us to train and practice with Microsoft Office in a simulated environment. Without providing details on what the name of this application is, I can assure you that it is owned by a reputable educational company. Looking back over some of my much older blog posts you can see that while using this application, I discovered that it lacked any encryption at all. In other words, when you logged into the application, your password and all other subsequent data was sent in "plain text" across the network.

I tried countless times, through e-mail correspondence, to explain to the application's support staff that they had provided an insecure application for numerous college students to use. Each and every time I attempted to explain the problem, along with how to rectify it, I was "brushed off." Initially, their support explained to me that users' passwords are stored in an encrypted database on their servers. While this may be true, that doesn't help with how the password are transmitted as plain text into said "secure" server. I even explained, in as simplistic of a manner as I could, how I was able to capture the network packets associated with a user's login request and could easily read the password from within them. This, however, was rebutted with, "you can only capture the packets from the computer you are on and not someone else's." Alas, I finally gave up. Clearly, support either did not understand what I was explaining to them, or they didn't want to admit that there system was unsecured.

Fast forward to the present day. It has been over four years since I made my initial discovery, and surely the very same web application now has some level of security implemented, right?

Upon first loading the website, which is now quite spiffy looking, I once again notice the lack of an "S" within the URL. Thinking that I might be able to manually specify that I would like to load the SSL variant of the login portal, I change the URL from "HTTP" to "HTTPS." Alas, an error.

Oops! Looks like it doesn't allow HTTPS...


Looks like we've ran into a problem all ready. Still having some hope that the web application may have some level of security, I start up WireShark to begin my packet capture and attempt to log into the system. Naturally, the login fails, however it still provides me with the network packets I wish to analyze. After digging down through the packets, I see the following:

What could this "gibberish" mean?


Looking through this part of the packet, you can see the username I chose, testuser, and what seems to be an encrypted password. Could this be true? Did they really implement encryption, finally, after all these years? In order to verify this, it seems like a look at the source HTML code is in order.

This JavaScript function doesn't look quite like what I was hoping for...


Going through the login portal's source code, it seems as if I've found the JavaScript function that performs the encryption of any provided password. Unfortunately, merely looking at the name of the function destroys what little hope i had left. It looks as if they have implemented MD5 hashing for their password "encryption." If you've never dealt with MD5 hashing, I implore that you do a little research into and and as to why it is a flawed method of securing password. Essentially, it has been outdated for quite a long time as a means of security. In order to show how very little security it has provided to this web application, let's see what happens when I take my "encrypted" password and upload it to an online MD5 decrypter.

Not so secure, is it?


As you can see in the provided image, that so-called "secure" portal is still quite insecure. Yes, they have made some changes to the way the login portal works, however there is still a lack of security.
Subscribe to RSS Feed Follow me on Twitter!