Azure-Sentinel

Azure-Sentinel copied to clipboard

Describe the bug The function module /MSFTSEN/USERS_DATA_GET in the provided transports NPLK900201 and NPLK900202 gives access to all details of a user. This includes the user authorizations and the password hashes.

To Reproduce Steps to reproduce the behavior:

1. Import one of the given transports, suitable for your system
2. create a simple script, that calls the fm /MSFTSEN/USERS_DATA_GET
3. authorize as a user with no rights to see other users
4. see all user data in the exported tables from the fm

Expected behavior If a user has no rights to see other users, the access should be blocked by an authorization check. This authorizations check should be done, before selecting any data, as all other RFCs do. A check similar to the transaction SU01 or SU03 seems appropriate. In this scenario (SIEM) it should not be necessary to provide the Password hash as well, so this export field should be deleted.

Workaround until fixed Deny access to the function module via RFC. On S/4HANA you can also use the report RS_RFC_BLACKLIST_CUSTOM

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

Hello, I wanted to ask for an update on this issue.

Hi @xamafe our team is looking into this issue, will update you shortly, thanks!

Hi, The function module /MSFTSEN/USERS_DATA_GET is calling the standard function module BAPI_USER_GET_DETAIL That is also RFC enabled and released by SAP.

It is fully protected under the relevant authorization objects and SAP RFC infra structure.

Another note is, that this function will be removed soon from the CR since we are using the standard BAPI_USER_GET_DETAIL in our agent now.

It is an optional step (configurable) but a recommended one to enhance the audit log with the user email

Hi @xamafe Gentle Reminder: We are waiting for your response on this issue. If you still need to keep this issue active, please respond on it in the next 2 days. If we don't receive response, we will be closing this issue as per our standard procedures, thanks!

Hi.

I saw no question for me, so I waited for a result...

My take on this:

• "Will be removed soon" is no date. That's some kind of "if we find the time, we will ....". That is IMHO not the correct approach to a security risk.
• If you wrap the functionality of a standard module you have to protect it, somehow. If the customer disables RFC-Modules by best-practice guidelines, the wrapper will still be accessible. In my opinion the wrapper creates a blind spot.
• There is still no point in exposing password hashes

Hi @udidekel Can you please provide an ETA for the removal of this function, thanks!

We are waiting to hear back from @udidekel, thanks!

Hi @xamafe, Gentle Reminder: We are awaiting for your response on this issue. If you still need to keep this issue active please respond on it in the next 2 days . If we don't receive response, we will be close this issue.

We are waiting to hear back from @udidekel, thanks!

Hi.

I saw no question for me, so I waited for a result...

My take on this:

• "Will be removed soon" is no date. That's some kind of "if we find the time, we will ....". That is IMHO not the correct approach to a security risk.
• If you wrap the functionality of a standard module you have to protect it, somehow. If the customer disables RFC-Modules by best-practice guidelines, the wrapper will still be accessible. In my opinion the wrapper creates a blind spot.
• There is still no point in exposing password hashes

Hi @udidekel please address author comments here, we are waiting for your update, thanks!

Waiting for update from @udidekel, thanks!

Hi.

I saw no question for me, so I waited for a result...

My take on this:

• "Will be removed soon" is no date. That's some kind of "if we find the time, we will ....". That is IMHO not the correct approach to a security risk.
• If you wrap the functionality of a standard module you have to protect it, somehow. If the customer disables RFC-Modules by best-practice guidelines, the wrapper will still be accessible. In my opinion the wrapper creates a blind spot.
• There is still no point in exposing password hashes

Hi @udidekel please take a look at the author concerns, thanks!

Hi All RFC functions are protected under S_RFC authorization object,

https://help.sap.com/docs/SAP_Solution_Manager/fd3c83ed48684640a18ac05c8ae4d016/b771a089a2e04e15bac4fa003baf88c4.html?version=7.2.05

usually as customers will maintain their own list of authorized RFC function that is maintained by the S_RFC object and by default RFC function are not allowed to be called for unauthorized users, to add on that the BAPI get user details, own its own Authorization object that need to be provided as well to the user.

Gentle Reminder: We are waiting for your response on this issue. If you still need to keep this issue active, please respond on it in the next 2 days. If we don't receive response, we will be closing this issue as per our standard procedures, thanks!

Since we have not received a response in the last 5 days, we are closing your issue as per our standard operating procedures. If you still need support for this issue, feel free to re-open at any time. Thank you for your co-operation.

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.