Skip to Content

SAP has released monthly critical patch update for March 2012. This patch update closes many vulnerabilities in SAP products. Overall, more than 40 vulnerabilities were fixed, including 7 found by third-party researchers.

I would like to tell you more about the corrected vulnerabilities and the risks that they involve.

  1. (1607850) SAP BW – critical information disclosure. No details are available. Criticality, according to CVSS, is 7.5.
  2. (1580244) SAP BASIS – missing authorization check in an RFC function. Criticality, according to CVSS, is 3.5.
  3. (1656549) SAP Portal – XSS vulnerability. An attacker can use the XSS vulnerability by sending a link to malicious script to an unaware user via an e-mail,  messaging or social networks. Thus, an attacker can gain access to user session and gain control over business-critical information which can                   be accessed by victim. Criticality, according to CVSS, is 4.3.
  4. (1657891) SAP BASIS – missing authorization checks in RFC function. Criticality, according to CVSS, is 2.3. An attacker can execute vulnerable transaction,  program or RFC function remotely without authentication because authorization check is missing. It can lead to different threats from               information disclosure to full system compromise.
  5. (1591427) SAP BASIS – XSS vulnerability. Criticality, according to CVSS, is 4.3.
  6. (1658947) SAP Portal – information disclosure. Criticality, according to CVSS, is 4.0.
  7. (1600755) SAP HR – ABAP code injection through missing input validity checks. Criticality, according to CVSS, is 6.0.

Today I will tell you about one of the most popular vulnerabilities, namely the missing authorization checks in RFC functions.

Overall, it is one of the most popular and most easily understandable types of vulnerabilities. Think about some RFC function which fulfills some critical action in the system; call it, for example, Z_RFCEXPLOIT (actually, the same applies to reports and transactions). The vulnerability is in the missing user authorization check (AUTHORITY-CHECK) in its code or use it with some mistakes. In practice, it means that the Z_RFCEXPLOIT function can be called by any user, provided that he or she has sufficient privileges to call RFC functions at all.

There are 3 basic ways to call an RFC function.

1.     In the dialog mode, using the SE37 transaction.
Privileged users usually have the rights for this kind of transaction though exceptions certainly exist.

2.     Through remote call by RFC protocol

In this case, apart from authorization check for RFC function per se, system also checks that user has the right to access the RFC functions group (S_RFC authorization, FUGR field). This mitigates the risk of attack, but the risk remains in the case of high privileged accounts with default passwords, like SAP*, DDIC, EARLYWATCH, TMSADM or SAPCPIC.
It is notable that the last two accounts are found in % 95 of the systems we analyze, so the chances of attack are pretty high.

3.     Though remote call by WEBRFC
It is commonly known that RFC commands can be called remotely through web interface located on the web port of SAP NetWeaver ABAP application server (relative address: /sap/bc/soap/rfc). What is specific about this method is that, first, in many organizations web interface is accessible through the Internet, and second, group authorization S_ICF is not assigned to this interface by default, which allows any user to make vulnerable RFC calls.

Thus, vulnerabilities connected with missing authorization should not be underestimated because they are easily exploited and do not require special privileges in the system. Taking into account that there are about 30k RFC functions and more than 2 million programs in SAP, such vulnerabilities will constantly reappear in SAP products, as well as in self-developed code whose security should be thoroughly cared about.

PS: According to ERPScan’s agreement with SAP we do not publish details of vulnerabilities until 3 months since update is released to give organizations time to install the patch.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Frank Buchholz

    1. I assume IT administrator take the authorizations for S_DEVELOP with OBJTYPE=FUGR and activity=16 (in former time activity 03) which enables the execution of functions in SE37 very seriously.

    2. I agree that any system owner has to get rid of these standard users like SAP* with standard password. There is no excuse to keep them!

    3. SAP Note 1394100 “Security note: Access to RFC-enabled modules via SOAP” suggests to deactivate the SICF service /sap/bc/soap/rfc if it’s not used. The note describes how to analyze web logs to detect if the service is used. Well, that’s a nice idea, but what should you do if the service is required?

    Anyway I wonder about your statement, that “group authorization is not checked when calling an RFC function through this interface”. Here’s a reference to the documentation stating that there is a check for S_RFC (but I didn’t have checked this yet):  

    Making the SAP Web AS SOAP-Capable
    http://help.sap.com/saphelp_47x200/helpdata/en/2d/64d03be74911d6b2e400508b6b8a93/frameset.htm

    By the way: In an ECC I find approximately 32000 RFC enabled functions (from 397000 functions in total) – which of course is still a very high number.

    Cheers,

    Frank

    (0) 
    1. Alexander Polyakov Post author

      Thanks for reply Frank.

      1) That’s true but I saw many systems with more than 200 users with such auths )

      3) I was meaning that S_ICF is not assigned by default

      About the functions it was a mistake, there are 2 million abap programs not remote RFC functions, sorry but anyway the number is too big.

      (0) 

Leave a Reply