Third critical area. Unnecessary functionality
What is the most common problem of any more or less complex application? In essence, they almost always have numerous unnecessary functions aimed to perform multiple tasks.
Obviously, that makes the whole system vulnerable. The more functionality is available, the higher becomes the number of vulnerabilities. "Complexity Kills Security"
More importantly, all those functions are enabled by default right from the start, thus making security threats inevitable. However, there is a growing trend that in every next following version of SAP there are positive changes concerning unnecessary functionality as more and more safety measures are being taken (extra functions are now deactivated by default).
Besides, very often those are not the functions themselves that make the whole system subjected to treats. It is evident that only those additional functions that are misconfigured can perform critical actions.
So, that is why it is crucial to regularly carry out security checks for misconfigured unnecessary functions. This critical area is the third one in our list and it involves three security assessment steps:
- [EASAI-NA-08] Access to the RFC-function via the SOAP interface;
- [EASAI-NA-09] Access to the RFC-function via the form interface Description;
- [EASAI-NA-10] Access to the Exchange Infrastructure (XI) via the SOAP interface;
But first, let us start with the basis. Web-applications and internal system objects (such as programs, transactions, RFC, etc.) - that is where most unnecessary functions are typically concentrated.
As far as it is quite easy for low-privileged or even anonymous users to get access to web-applications via the Internet, the decision was taken to describe in the present article only the checks related to web-applications.
Also, when it comes to the ways of getting access to web-applications we should keep in mind that it is the Internet Communication Framework (ICF, the SAP Web Application Servercomponent) that makes it possible to implement standard protocols, such as HTTP, HTTPS and SMTP for intersystem connections management via the Internet.
Further steps
Standard environment contains about 1500 various web-services that are available remotely on behalf of any registered user. Also, about 40 services are accessible to anonymous users. Note that remote access is only possible if the service was enabled by default.
Besides, after you have completed the three checks mentioned in this article, you should also disable all the services that anonymous users can get access to. Secondly, you should analyze all the installed services in order to detect those of them are not necessary for the system. Lastly, restrict access to the necessary ones using additional authorizations.
Check out «Secure Configuration of the SAP NetWeaver Application Server Using ABAP» [1]. In this paper 13 critical services are indicated. As mentioned above, those are only the main, basic services.
Another step to be taken, after you have completed web-services configuration is disabling all unnecessary internal functions, such as unnecessary critical transactions, programs, profiles, roles, etc. This step requires a thorough analysis of each module in each particular case.
Nevertheless, there are several transactions within the productive system to be disabled (1 see the paragraph end). They are mentioned in ISACA guides[2].
For the record, in the present guideline we only recommend you to do this, this item was not included in the main list because it only has to do with productive systems.
Transactions recommended to be blocked (disabled):
- archive administration: KA10, KA12, KA16, KA18, SARA;
- reset transaction data: OBR1;
- structural authorization OICP, OOSB;
- user maintenance: OMDL, OMEH, OMWF, OOUS, OPF0, OTZ1, OY27, OY28, OY29, OY30;
- profiles: OMEI, OMWG, OOPR, OP15, OPE9, OTZ2, OY21;
- privilege and profile maintenance: OMG7, OMWK, OPF1, OTZ3, OY20;
- structural authorization: OOSP;
- maintenance of user profiles: OVZ6;
- copy by transport request: SCC1;
- deleting a client: SCC5;
- transport organizer (extended): SE01;
- workbench organizer: SE09, SE10;
- table maintenance: SE16, SM30, SM31; external OS commands: SM49, SM69;
- deleting all users: SU12.;
[EASAI-NA-08] Access to RFC-functions via the SOAP interface
Description
RFC stands for Remote Function Call. Accordingly, RFC is a SOAP-interface based service which allows to get remote access to some of the functional modules, also called RFC-functions. This service is available by the following link: /sap/bc/soap/rfc.
Firstly, you need to have /sap/bc/soap/rfc service activated. Secondly, you need to have legitimate system or default user with a default password available in the system. In this case, it becomes possible to access and execute RFC-functions of the ABAP platform.
Threat
One can start RFC-function execution via HTTP channel using SOAP requests. Sometimes SOAP requests are even sent from the Internet.
An adversary can use default account details to gain access to RFC service. Subsequently, having access to RFC crevice one can carry out various types of attacks. For example, a regular user with any set of privileges can perform a DoS attack using incorrect SOAP request.
Solution
Providing that you have /sap/bc/soap/rfc service activated, make sure that the number of users allowed to access RFC is somehow restricted. Whereas, if there is no real need to use RFC, deactivate it using SICF transaction.
[EASAI-NA-09] Access to the RFC-function via the form interface Description
When it comes to /sap/bc/FormToRfc service, we should bear in mind that this service is intended only for internal needs of SAP. It should be by no means kept within the production system. The reason is that this service misses some authorization checks. Starting from the version 6.20, this service's functions are performed by the SOAP (/sap/bc/soap/rfc). As regards to ICF services, they are disabled by default.
Threat
It is risky to use /sap/bc/FormToRfc service within the production system, as it lacks some authorization checks. One can exploit this vulnerability using RFC-function, and get an unauthorized access to any business data.
Solution
In case the /sap/bc/FormToRfc service is not used, it is highly recommended to deactivate it with the help of SICF transaction.
[EASAI-NA-10] Access to Exchange Infrastructure (XI) via SOAP interface
Description
SOAP interface based surface which is used to access the so-called Exchange Infrastructure (XI) may be implemented to remotely call some critical functions. Moreover, it allows to send requests to a third- party system.
Threat
On the condition that the service was activated incorrectly or the number of restrictions is insufficient, it becomes possible to start execution of XI-function via HTTP channel using SOAP requests. Sometimes SOAP requests are even sent from the Internet.
An adversary can use default account details to gain access to this service. In this case one can carry out various types of attacks, both on the target system and on those systems that are integrated with it depending on the type of performed function, which is set in the Enterprise Service Bus. In the worst-case scenario, an adversary may get an unlimited access to this server together with the related ones.
Solution
In case the service is not used, it is highly recommended to deactivate it with the help of SICF transaction. Otherwise, it is better to set up additional access restrictions. To do that, you should put into practice the use of appropriate authorizations or network access control procedure.
Summarizing our discussion let us once again remind you of the fact that presently no ERP system is immune to security threats. There is no exception to this rule. That is why solid information should be regularly provided on how to rise security control to higher levels.
Next time we'll come back with a description of new security assessments procedures concerning the fourth critical area from our list. Bye, and remember to keep a wary eye on business data.
Comments